I am using Twitter4j streaming API. I am using a geolocation constraint to get the tweets only from a specific area. Here is that part of the code:
twitterStream.addListener(listener);
String[] keywordsArray = { "iphone", "america", "samsung" };
FilterQuery filterQuery = new FilterQuery();
filterQuery.track(keywordsArray);
double[][] locations = { { 40.714623d, -74.006605d },
{ 42.3583d, -71.0603d } };
filterQuery.locations(locations);
twitterStream.filter(filterQuery);
This actually returns me results but almost all the tweets come with geolocation as NULL. One out of 25-30 (or even more)tweets will have a geotag. Can anyone point me to what am I missing?
As far as I know, twitter streaming API does not allow searching by both keyword AND location. Your code is searching for tweets which either have the keywords:{ "iphone", "america", "samsung" } OR belong to the location: { { 40.714623d, -74.006605d },{ 42.3583d, -71.0603d } }.
Hence the tweets that you are getting which have a geo tag are the ones which belong to the given location while others are due to the given keywords.
Related
My aim is to reduce the json file size, which contains the base64 image sections of the documents by default.
I am using the Document AI - Contract Processor in US region, nodejs SDK.
It is my understanding that setting fieldMask attribute in batchProcessDocuments request filters out the properties that will be in the resulting json.
I want to keep only the entities property.
Here are my call parameters:
const documentai = require('#google-cloud/documentai').v1;
const client = new documentai.DocumentProcessorServiceClient(options);
let params = {
"name": "projects/XXX/locations/us/processors/3e85a4841d13ce5",
"region": "us",
"inputDocuments": {
"gcsDocuments": {
"documents": [{
"mimeType": "application/pdf",
"gcsUri": "gs://bubble-bucket-XXX/files/CymbalContract.pdf"
}]
}
},
"documentOutputConfig": {
"gcsOutputConfig": {
"gcsUri": "gs://bubble-bucket-XXXX/ocr/"
},
"fieldMask": {
"paths": [
"entities"
]
}
}
};
client.batchProcessDocuments(params, function(error, operation) {
if (error) {
return reject(error);
}
return resolve({
"operationName": operation.name
});
});
However, the resulting json is still containing the full set of data.
Am I missing something here?
The auto-generated documentation for the Node.JS Client Library is a little hard to follow, but it looks like the fieldMask should be a member of the gcsOutputConfig instead of the documentOutputConfig. (I'm surprised the API didn't throw an error)
https://cloud.google.com/nodejs/docs/reference/documentai/latest/documentai/protos.google.cloud.documentai.v1.documentoutputconfig.gcsoutputconfig
The REST Docs are a little more clear
https://cloud.google.com/document-ai/docs/reference/rest/v1/DocumentOutputConfig#gcsoutputconfig
Note: For a REST API call and for other client libraries, the fieldMask is structured as a string (e.g. text,entities,pages.pageNumber)
I haven't tried this with the Node Client libraries before, but I'd recommend trying this as well if moving the parameter doesn't work on its own.
https://cloud.google.com/document-ai/docs/send-request#async-processor
I've been trying to retrieve all GitHub issues of a specific project using their GraphQL API.
The problem that i have is that i need to specify in the items a first or last param it doesn't work. Although by specifying one of these params i get only a partition of the issues.
I thought that i could get the first 100, then use pagination and get the other 100 etc until the response is an empty list. From what i read, i cannot find a parameter in the items that defines a page.
What are your thoughts on this? Is there a workaround?
Thanks a lot for your time.
This query seems to work fine and gives page info under items,
query{
organization(login: "microsoft") {
projectV2(number: 559) {
title
items(first: 100) {
pageInfo {
endCursor
hasNextPage
}
}
}
}
}
Output,
{
"data": {
"organization": {
"projectV2": {
"title": "Azure TRE - Engineering",
"items": {
"pageInfo": {
"endCursor": "Njc",
"hasNextPage": false
}
}
}
}
}
}
Tested the query using,
GitHub Explorer
Hi I am creating documents with commit like this way:
{
"writes": [
{
"update": {
"name": "projects/projectID/databases/(default)/documents/test/?documentId=",
"fields": {
"comment": {
"stringValue": "Hello World!"
}
}
}
},
{
"update": {
"name": "projects/projectID/databases/(default)/documents/test/?documentId=",
"fields": {
"comment": {
"stringValue": "Happy Birthday!"
}
}
}
}
]
}
The parameter ?documentId= dosen´t work like when creating a single document, if I left empty I get an error that I must specify the name of the document so how I can generate an automatic id for each document?
Unfortunately, batch commits with auto generated documentId are not possible in the Firestore REST API. As you can see in this documentation, the Document object should be provided with a full path, including the documentID:
“Name:string
The resource name of the document, for example projects/{project_id}/databases/{databaseId}/documents/{document_path}.”
And if it was possible to omit the documentID, it would be mentioned in this documentation.
If you would like to have this implemented in the Firestore REST API, you can create a feature request in Google’s Issue Tracker so that they can consider implementing it.
I just came across the same problem and discovered that it is still not implemented.
I created a feature request for it here: https://issuetracker.google.com/issues/227875470.
So please go star it if you want this to be added.
working with a MEAN Stack and I have three GET requests for the same URL/Route. One is to get a generalised summary of long-term emotions, the other is to get a summary of emotions by dates entered, and lastly, a summary of emotions related to a user-entered tag associated with individual emotion entries.
My first GET request is throwing no issues but the second GET request throws an error: Cannot read property 'length' of undefined
The error points to the following line:
48| each emotion in dateEmotions
Below is the relative code associated with the error:
Jade
each emotion in dateEmotions
.side-emotions-group
.side-emotions-label
p.emotion-left= emotion.emotionName
p.pull-right(class= emotion.emotionLevel) (#{emotion.emotionLevel}%)
.side-emotions-emotion.emotion-left
GET Request
module.exports.emotionsListByDates = function (req, res) {
Emo.aggregate([
{ $match :
{ "date" : { $gte: ISODate("2018-04-09T00:00:00.000Z"), $lt: ISODate("2018-04-13T00:00:00.000Z") } }
}, { "$group": {
"_id": null,
"averageHappiness": {"$avg": "$happiness"},
"averageSadness": {"$avg": "$sadness"},
"averageAnger": {"$avg": "$anger"},
"averageSurprise": {"$avg": "$surprise"},
"averageContempt": {"$avg": "$contempt"},
"averageDisgust": {"$avg": "$disgust"},
"averageFear": {"$avg": "$fear"},
}}
], function (e, docs) {
if (e) {
res.send(e);
} else {
res.render('dashboard', {
title: "ReacTrack - User Dashboard",
pageHeader: {
title: "User Dashboard",
strapline: "View your emotional data here."
},
dateEmotions: docs
})
}
});
};
This question is already getting pretty long, but I have another GET Request pointed to that URL and it is not throwing any errors, and the only difference is that I am not matching the db records by date in that query. I can post the working code if need be.
Edit
After some experimenting, I am able to get each of the three routes working individually if I comment out the other two. It's when multiple routes pull in the multiple requests that causes issues. For example, here are the routes at present where the ctrlDashboard.emotionsListByDates is working:
// Dashboard Routes
//router.get(/dashboard', ctrlDashboard.emotionsListGeneralised);
router.get('/dashboard', ctrlDashboard.emotionsListByDates);
//router.get('/dashboard', ctrlDashboard.emotionsListByTag);
If I comment out two routes and leave one running, and comment out the respective each emotion in emotions each emotion in dateEmotions and each emotion in tagEmotions blocks in the Jade file and leave the correct one uncommented, then that route will work, it seems to be when I am firing multiple routes. Is this bad practice, or incorrect? Should all queries be in the one GET request if on the same URL?
Thanks.
Apologies, new to routing and RESTful APIs but after some researching into the topic, I now understand the fault.
I assumed that the URL used in routing was the URL you wanted the data to populate...which it still kinda is, but I thought if I wanted to populate the dashboard page, I had to use that exact route and I did not realise I could post the data to different URL routes and take the data from those URLs to populate the one page.
Fixed by adding /date and /tag to those routes and using AJAX to perform those requests and populate the main page.
Thanks all.
I have the same problem but I'm using React+Redux+Fetch. So is it not a good practice dispatch more the one request in the same time and from the same page to a specific url?
I would know what causes that problem. I've found some discussions about it could be a mongoose issue.
My code:
MymongooObject.find(query_specifiers, function(err, data) {
for (let i = 0; i < data.length; ++i) {
...
}
}
Error:
TypeError: Cannot read property 'length' of undefined
I'm using Facebook Graph API to get all the photos of a user graphPath: me/albums and find something weird with Timeline Photos album.
Photos exist in Timeline album on Facebook, but not returned from API call graphPath/{timeline_photos_album_id}/photos, or they are returned with lower number of photos.
What is the problem?
Logs:
Calling for albums graphPath: me/albums:
.....
{
"can_upload" = 0;
count = 3; !!!!!!!!!!!
"created_time" = "2013-06-18T10:43:27+0000";
description = cool;
from = {
id = 100006100533891;
name = "Mike Mike";
};
id = 1387760311437307;
link = "https://www.facebook.com/album.php?
fbid=1387760311437307&id=100006100533891&aid=1073741829";
name = "Timeline Photos";
privacy = everyone;
type = wall;
"updated_time" = "2013-06-18T10:47:53+0000”;
},
.....
Calling for album photos graphPath/{timeline_photos_album_id}/photos:
{
data = (
);
}
Unfortunately "it is not a bug, it is by design".
I tried the following (with "user_photos" permission) and it works:
Fetch the album photo count for my user:
https://graph.facebook.com/me/albums?fields=id,count&access_token={access_token}
The result is
{
"data": [
{
"id": "{album_id}",
"count": 161,
"created_time": "2010-11-05T15:41:42+0000"
},
....
}
Then query for the photos of this album:
https://graph.facebook.com/{album_id}/photos?fields=id&limit=500&access_token={access_token}
The result is
{
"data": [
{
"id": "{photo_id1}",
"created_time": "2013-12-29T09:59:52+0000"
},
{
"id": "{photo_id2}",
"created_time": "2013-12-17T10:40:26+0000"
},
...
}
I count the correct number of 161 ids in the result. So everything seems to work fine.
You can also test this via FQL:
https://graph.facebook.com/fql?q=select+pid+from+photo+where+album_object_id+=+{album_id}+limit+1000&access_token={access_token}
there have been changes in the FB API recently, did you try to add the fields you want to get back in the result from the API? In the past, API always returned "standard fields", newest you always have to provide a list of fields of what you want to have back in the result such as ....fields=name,id...
I think you are missing the user_photos permission in the Access Token. The end point:
/{timeline_photos_album_id}/photos is working perfectly fine for me when I tried it using the Graph API Explorer to retrieve photos from my Timeline photos album. And, I don't think that it is necessary to provide the fields.
I'll suggest you should try the same using the Graph API Explorer. Just press the Get Access Token button on the top right and check the user_photos permission to test your request.
In case you are getting lesser results, you can try your query using pagination options limit and offset. This sometimes returns more results as compare to normal(nothing about this on docs, just my personal experience). Something like:
{timeline_photo_album_id}/photos?limit=500&offset=0
But again, as you pointed out, there are strange things going on with the API. Take a look at this article. This article refers to it as an expected behavior of the API!