I am trying to get the proper output from the API but each time it throws an error, and not having enough information about the error makes it more default here is the below example and same happened with other files too
{
"Usage": "0.47476506233215",
"Resource": "/photoscene/XkQN53pc1WCI66ExM6DnjVmKCYb6ZyRZ8ntmwdTjj8U/progress",
"Photoscene":
{
"photosceneid": "XkQN53pc1WCI66ExM6DnjVmKCYb6ZyRZ8ntmwdTjj8U",
"progressmsg": "ERROR",
"progress": "100"
}
}
What are the guidelines for the input images?
Do we have any sample input images for POC?
Thanks in advance!!
From what I've seen, these errors are often caused by insufficient input data. For example, check out this Stack Overflow question: Error: Processing is failing in Autodesk-Forge when converting the image to 3D.
Consider providing more information about your particular case - how many images have you used to reconstruct the scene, what resolution/quality were they?
Related
I am using https://github.com/Autodesk-Forge/recap-walkthrough-photo.to.3d for converting image to 3D, but at the end of the execution its throwing an error when the image is getting processed.
Any Help on this would be highly appreciated.
data: {
Usage: '0.44537496566772',
Resource: '/photoscene/jsjshdfjsdhgjfsdjf/progress',
Photoscene: {
photosceneid: 'jsjshdfjsdhgjfsdjf',
progressmsg: 'ERROR',
progress: '100'
}
}
is the error. Reason for this error is not coming.
Please contact the support via forge (dot) help (at) autodesk (dot) com, providing as much information as possible, e.g.:
how many images you uploaded, and what was their resolution?
how did you upload these files? If you used a custom code or script, could you share it?
when did you run these requests, and what was the Forge Client ID you used for them?
EDIT:
While the response isn't very descriptive, the engineering team confirms that this error is typically caused by insufficient input data. In this particular case only 4 images were uploaded, and the algorithm wasn't able to reconstruct the 3D screen from those.
We're using the shared Forge activity "AutoCAD.PlotToPDF+prod" to get back a plotted DWG in a PDF file, but the resulting PDF is missing the last layout from the DWG. However, there see to be some cases where the last page does get included. There are no obvious differences between the DWGs that include the last page when plotted to PDF and those who don't. Is there any reason why these shared Forge activity wouldn't include the last layout from the source DWG?
This is something that's holding us up from completing a large feature implementation before deploying it to production, so we'd like to find out if we're not going to be able to use the shared activity to make this work so that we can implement a work-around and prevent missing the deadline for delivery.
Thanks in advance.
Here is an example of the input versus output.
The provided drawing is dependent on external reference "background.bmp" as overlay, Forge Design Automation is not aware of the dependent reference, you need to provide that as well.
If your drawing depends on external files, you need to zip them and send, and make sure to provide path of main drawing that to be processed in pathInZip argument of workitem.
For example
{
"activityId": "AutoCAD.PlotToPDF+prod",
"arguments": {
"HostDwg": {
"localName": "Outputs",
"pathInZip": "Output.dwg",
"url": "downloadUrl",
"verb": "get"
},
"Result": {
"url": "uploadUrl",
"verb": "put"
}
}
}
What format should I return the response to the API user if an error occurred? Just return the response as a status code and error message:
Full authentication is required to access this resource
(the status 401 was returned)
Or it is better to return it in this format:
{
"timestamp": "2020-06-14T21:20:52.941+0000",
"status": 401,
"error": "Unauthorized",
"message": "Full authentication is required to access this resource",
"path": "/api/users/me"
}
Well, it depends:
If you know your front end urgently requires the direct message of the error, ignoring anything else, then going for the short and direct to the point answer might be your best choice.
But honestly, if experience in programming has taught me anything, is that the more information you have about something, the better, ESPECIALLY IF IT'S an ERROR!!! With the longer response, you have many more tools in you hand, both for giving the final user a better look of your application - You can present for the user a small title, a detailed message and, for example, use an internal code to show a red "error" box if a fatal error ocurred or a "warning" yellow box if a validation simply failed - and especially for the dev to solve that problem (The final user might never see the "timestamp", "status", "path" or stacktrace of the error - He shouldn't... - But it will surely help you track what caused the error).
Take a look at these (1, 2 and 3) articles to help you decide your situation and, if needed, customize your error response structure
If I go to the following location:
https://maps.googleapis.com/maps/api/place/radarsearch/json?location=51.5112139,-0.1198244&types=lodging&radius=3200&sensor=false&key=yourKey
I get the error:
{
"debug_info" : [],
"html_attributions" : [],
"results" : [],
"status" : "UNKNOWN_ERROR"
}
Is there any reason for this?
When I lookup Bristol(51.454513,-2.58791), Ipswitch(52.056736,1.14822) or Edinburgh(55.953252,-3.188267) I get a normal JSON file back full of data.
I don't know how Google works internally.
Unknown error simply means to me that "We have an error with your request, and we don't want you to know what the exact error is". Most of time, it is from the internal exception handling process.
Honestly, I don't know what happens in Google.
However, if you change your radius from 3500 meter to 2000 meter, it works fine
https://maps.googleapis.com/maps/api/place/radarsearch/json?location=51.5112139,-0.11982439999997041&types=lodging&radius=2100&sensor=false&key=key
My guess is there are too many results, and Google cannot handle that much.
I don't know why but the URL works sometimes, and sometimes doesn't work.
The "UNKNOWN_ERROR" status may be internal error of Google.
To prevent the error temporally, shorten the radius.
And report this to the gmaps-issues-tracker.
https://code.google.com/p/gmaps-api-issues/
Rank by distance seems to have some issues with radius. Is this implied in your situation?
Google
Stack Overflow
After uploading a file with a name conflict with existing one, the server still responds with HTTP status code 201 Created. I had to parse the response body to know exactly whether it is really created or not. It sounds to me that I should be able to know the result of the operation just by the status code. So I am wondering if this is an intended behavior.
The following is the response I get
{
"total_count":1,
"entries":[
{
"type":"error",
"status":409,
"code":"item_name_in_use",
"context_info":{
"conflicts":[
{
"type":"file",
"id":"2990420477",
"sequence_id":"0",
"etag":"1f64ca909178de30bc682a4ca2d14444719cf9a2",
"name":"Extensions.pdf"
}
]
},
"help_url":"http:\/\/developers.box.com\/docs\/#errors",
"message":"Item with the same name already exists",
"request_id":"1389504407503c7c1e8183c"
}
]
}
We are in the process of changing this from a 200 to a 202. Later this week (or possibly tonight) we'll roll out a change to make upload statuses be 202's, to show that the upload request has been accepted. I'll post a bit more on our blog to explain more details.
The basic logic is that uploads can be sent in bulk, and the API call has to return you an array of upload statuses (stati?). If you only upload one file, you'll get an array of 1, and you'll have to dig into the array to see if you were successful or not. If you upload a group of files, then you'll be digging into the array to find out the status of each file.
You might ask: Why not collapse the status when there is only one file? Our thought there is that you'd have to implement 2 different code paths to deal with single vs bulk-upload, and it would be easier to just write the code once to handle uploads either way.
Hope that helps. Let us know if you see unexpected behavior after we flip the error code over from the 200 to the 202.