The current Batch Geocoder Introduction page states:
"Note: This service is no longer being actively developed. We will only provide critical fixes for this service in future. Instead, you can use the new Geocoding and Search API v7 service."
I do not see mention of geocoding large dataset of addresses in the "Geocoding and Search API v7" API Reference. As a matter of fact, the "Geocoding and Search API v7" API Reference webpage is titled, "Geocoding and Search API v1 (1.0)" which is also strange.
Is the Batch Geocoder nearing end of life? If so, does any documentation exist that describes the new approach to geocoding large datasets?
Not at all..now v7 is the newer API with more features and will keep on offering new features and will be actively developed. The older version is no more actively developing. Also v7 API offers to use Geocoder API with our platform (Cloud based product). The additional benefits are as follows :
HERE Geocoding and Search leverages the freshness, breadth and depth of HERE Map Content
It provides a rich and comprehensive set of capabilities that enable you to build applications that your end-users need and desire.
It is fully integrated in the HERE Platform to enable you to create, process, ingest and search your own data sets. (Note: Bring Your Own Data capabilities are only available to customers with a HERE Platform Workspace license.)
Related
I want to know how wso2 api manager integrates solr; why the search logic relies on solr instead of the database, and sometimes the records obtained by getallApis are not consistent with the number of records in the database table AM_API.
As the documentation states WSO2 API Manager has Apache Solr based indexing for API documentation content. It provides both the API Publisher and Developer Portal a full-text search facility to search through the API documentation, and find the documents and related APIs.
I would recommend you to check out an excellent technical answer of #jpountz. Event though, the comparison made between postgresql vs lucene (underlying library is used by solr), it will give you some insight on why it's been chosen search engine (Lucene in the case wso2) over databases.
In my application , I use the following APIs of the companies API,
https://api.linkedin.com/v1/companies/id={id}
and
https://api.linkedin.com/v1/companies/{id}/updates?event-type=status-update
With the new API program, do I need to change my existing application ? I find the description on the linkedin developer website regarding the same as not comprehensive enough. If I need to continue with the app, do I really need to get into a partnership program with linkedin or can I continue like I do currently.
We recently contacted the LinkedIn Support regarding the changes.
So first endpoint will be available to you without getting into PartnerShip program. The following endpoints are the only ones that will remain available for use:
Profile API — /v1/people/~
Share API — /v1/people/~/shares
Companies API — /v1/companies/{id}
The second Endpoint will require Partner Ship program with LinkedIn you can apply here
But it will not involve code changes because they will give privileged access to your App. At the time of applying for partnership program they will ask for LINKEDIN_APP_KEY and LINKEDIN_APP_SECRET. They will provide access to these KEY and SECRET.
I have a custom Windows service developed in C#.NET that synchronizes users' Google calendars with an internal calendar.
Per the Google Calendar API documentation, I'm using the below code. I believe this is referred to as the ClientLogin method which may or may not be advised (I've found conflicting information in the Google documentation).
CalendarService service = new CalendarService("Your app name");
service.setUserCredentials("username", "password");
This worked fine in testing. Now that things have moved to production, I'm receiving errors such as "The user has exceeded their quota, and cannot currently perform this operation" and "User has modified too many events today. Please try again tomorrow." This began more than a day ago and has remained as such.
I've researched this considerably and am still confused on a few points. Any help would be greatly appreciated.
What is the daily quota per user?
Are the (really low?) quotas there because an API key isn't being used by my application?
If I were to use an API key, which approach would I use for a Windows service in which I have the usernames and passwords for the Google users? - Simple API, OAuth2, Service Account, etc.
FYI: I am using the API .NET library provided by Google. If I should be using a particular authentication approach, I would appreciate a sample illustrating the implementation using the .NET library provided via Google.
First of all you definitely don't use the latest version of the library. You can download it from NuGet. You should download the following two packages:
https://www.nuget.org/packages/Google.Apis.Calendar.v3/
https://www.nuget.org/packages/Google.Apis.Authentication/ (be aware that in the next release we are going to improve the OAuth2 flows significantly, and support WP, Windows 8 application).
Regarding your questions:
1-2) Calendar API supports 100,000 requests/day. You can find that information in the Google API Console in the services tab.
3) Definitely OAuth2. Read more here and here.
You can find code samples with the current implementation of OAuth2 in our samples repository (https://code.google.com/p/google-api-dotnet-client/source/browse/?repo=samples)
Is it possible expose and sell google cloud endpoint as an Api? I have created a simple but useful cloud endpoint. I want paid customers to access it directly as an api. How will I create a client-Id or API key dynamically for such clients, etc? For example, google also sells search service as API, where any user can go generate its own API key and Secret, and start using google search service.
Right now, no, or at least not without a lot of work.
The current product was designed with the "same party" use case as the primary goal (the API producer and consumer are the same). There are a number of things that would need to be added to the product to enable the kind of use you're describing. First and foremost on that list would be some kind of API consumer dashboard (like the one Google offers developers for consumers of its APIs).
Endpoints is built on the same API infrastructure as the rest of Google's APIs, and Google does offer this feature on some of its APIs. That may give you a sense of where the product is headed in future iterations.
Prior to iOS 6, the ios maps api had restrictions for developers, imposed by Google, some of which are the following:
10.9 use the Service or Content with any products, systems, or applications for or in connection with:
(a) real time navigation or route guidance, including but not limited to turn-by-turn route guidance that is synchronized to the position of a user's sensor-enabled device;
(b) any systems or functions for automatic or autonomous control of vehicle behavior; or
(c) dispatch, fleet management, business asset tracking, or similar enterprise applications (the Google Maps API can be used to track assets (such as cars, buses or other vehicles) as long as the tracking application is made available to the public without charge. For example, you may offer a free, public Maps API Implementation that displays real-time public transit or other transportation status information.
(taken from http://code.google.com/apis/maps/iphone/terms.html. Apple's Map Kit framework also points there.)
Are these restrictions still in place for ios 6, despite Google no longer providing the maps? Searched the web (and Apple's documentation) for an answer but came up short.
I'm going to build an app that manages a company's rental car fleet (private) and need to use a maps solution for just that. Up until ios 6 I was leaning towards using openlayers + webview but would rather use a native solution if possible.
Thank you in advance.
Maybe that's not the case, but seems that if you use CoreLocation to obtain vehicle location and then use in somehow for fleet management, you're not allowed to do that as far as it contradicts the App Review Guidelines 4.3:
4.3
Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected
UPD (1.feb.15): As lan noticed, this guideline is no longer present in the list.