Is there a way to determine how many records are available to download for a socarata table?
I'm using the API endpoint routines. I can down the file but it would be nice to know how many records are available to download before starting a download.
If I understand the question right, the most straightforward way would be to view the source dataset.
Example: https://data.cityofchicago.org/Transportation/Transportation-Network-Providers-Trips/m6dm-c72p
Screen clip of "What's in this Dataset?"
Screen clip of more precise count from the bottom of the data preview grid
However, you can also do it through the API.
Example: https://data.cityofchicago.org/resource/m6dm-c72p.json?$select=count(*)
[{"count":"100717116"}]
Related
I am currently in the process of implementing pagination, sort and search functionalities in the project files/plans/sheets views of BIM 360 Docs integration.
Since I couldn't find any best practices regarding to these features, I thought I would reach out so that I don't keep stuck reinventing the wheel.
Background:
Most of the implementation uses https://github.com/Autodesk-Forge/forge-api-dotnet-client/ SDK.
Based on what I saw, pagination in Autodesk API is very basic and does not play well with filtered views. Please correct me if I am wrong, but it looks like there is no way to get number of items in the view and/or calculate total number of pages in the resultset.
If one uses filtering to limit types of items returned by the API (e.g. documents, sheets, project files), API applies pagination first and filters second. That causes holes in returned resultsets, e.g. one would request page 1 sized as 5 items, and get 3 items back, then request similarly sized page 2 and get no items back, then page 3 would yield 2 items.
The above mentioned issues force us to use dynamic lazy-loading paging, similar to how it's currently done in the BIM360 Docs UI.
Question:
Is there a different, better way to paginate? Or do we have to lazy-load results while scrolling, never knowing how much records the next page would return?
Unfortunately, paginating is not available for Forge MD API of BIM360 currently as I know. Apologizing for any inconvenience caused.
However, it's been logged as request id FDM-1769 a few days ago. I saw your name on the request list. So I think it will be supported in the future. Besides, a workaround is to fetch all data from the API, then paginate on the client side via Javascript.
I have very important question for me. I would like to use Autodesk Reality Capture API in my app. I read the documentation to API but I did not find it. I know the position of camera and i would like to send this information to Reality Capture API. For example circle was divided in 24 parts. So I know that each photo was made every 15 degrees. Is there any parameter which gives me possibility to provide the position of camera?
There is no way of passing this kind of information to Reality Capture API (at least no official way) and even if it is debatable, there is not much use for such input.
Roughly speaking, the engine will “stitch” the given images based on common pixels/regions/patches. For complex objects, each 15 degrees might not be enough to capture the complex geometry and you will have to add more photos aiming that specific region.
The main benefit is that you can process your images, get the result, see the missing or low detail spots, take a bunch of photos of those specific spots and add them to the project, process your project again and repeat till you get a satisfying result. From this perspective, the "rule" of photos taken each 15 degrees will break very fast.
If you are getting wrong results, 80% of the time (again the Pareto principle) this is caused by missing the scenetype parameter, which defaults to aerial, when usually people expects to use the object type.
Check The Hitchhiker's Guide to ... Reality Capture API for more details.
I need to fetch a list of all the files in a user's box account, such that the list of files can then be displayed in a table view (iOS).
I have successfully implemented this by recursively using /folders/{folder id}/items on all the folder's in my user's box.
However, while this works, it's kind of dirty, seeing as how a request is made for each of the users's folders, which could be quite a large number.
Is there any way to get a list of all the files (it's no issue if folders are included, I can ignore those manually) available?
I tried implementing this using search, but I couldn't identify a value for the query parameter that returned everything.
Any help would be appreciated.
Help me, Obi-Wan Kenobi. You're my only hope.
What you are looking for (recursive call through a Box account) is not available. We have enterprise customers will bajillions of files and millions of folders. Recursively asking for everything would take too long.
What we generally recommend is that you ask for as little as you can, and that you use multiple threads and anticipate what you'll need just a little bit, so that you can deliver a high-performance user-interface to your end-users.
For example ?fields=item_collection is expensive to retrieve, and can add a lot to a paylaod. It can double, or 10x the time that it takes to get back a payload from the Box API. Most UI's don't need to show all the items inside every folder. So they are better off asking for ?fields=.
You can make your application responsive to the user if you make the smallest possible call. Of course there is a balance. Mobile networks have high latency, and sometimes that next API call to show some extra thing is slow. But for a folder tree, you can get high performance by retrieving only the current level, displaying that, and then starting to fetch one-level down while the user is looking at the first level.
Same goes for displaying thumbnails. If a user drills into a folder and starts looking at thumbnails for pictures, there's a good chance they'll want to see other thumbnails in that same folder. Your app should anticipate that, and start to pull one or two extras down in the background. Yes, it means more API calls, but your users will give your app a higher rating for being fast.
I am creating an option in my application to create a PDF report based on the results from the application.
The results are represented as an ArrayCollection of XMLList objects, which I am using to populate a BarChart.
To create a screenshot of each result (as a PNG), I am loading the Results Window (a Title Window) and hiding it (visible = false). I am using AlivePDF to add the capture to a PDF report.
I have been using a Timer to iterate through the results, load each result to the chart, create a delay, and then capture the image and add it to the report.
I am now questioning my strategy and I was wondering if anyone has a suggestion as to any other possibilities.
I thank you for your help in advance.
P.S. I am not creating a client/server application. I need to create the images on the client side.
UPDATE
Sorry about the confusion with my question.
Currently, I am able to iterate through the results (using the Timer), but the chart does not refresh properly before capturing the screenshot and saving as PNG.
Essentially, I am trying to see if there is any other possible solutions for iterating through the results and creating a delay so that I may be able to load a result to the chart, capture the screenshot, and add it to a PDF. Is there any other way to do this in Flex?
Initially, I was thinking of iterating through the results array using a for loop, but this was not working due to the fact that the results were not loading in time before capturing the screenshot of the chart.
Once you set the chart's data it should eventually display the updated information. However the time taken will vary upon any number of factors so your best bet is to find out what event the chart dispatches once it updates. You may at that point want to capture the PNG as a callLater just in case you need an extra frame before the visual aspects are updated.
That said, this seems like a heavy-handed solution begging for an alternative.
I am working on a project converting a "spreadsheet application" to a database solution. A macro was written that takes screen shots of each page and pastes them into a PowerPoint presentation. Because of the nice formatting options in Excel, the presentation looks very pretty.
The problem I'm having is that I haven't ever seen an Access report that would be pretty enough to display to upper management. I think the output still has to be a PowerPoint presentation. It needs to look as close as possible to the original output.
I am currently trying to write some code to use a .pot (presentation template) and fill in the data programmatically. Putting the data into a PowerPoint table has been tricky because the tables are not easy to manipulate. For example, if a particular description is too long, I need to break into the next cell down (word-wrap isn't allowed because I can only have n lines per page).
Is there a way to make an Access report pretty, am I headed down the right path, or should I just try to programmatically fill in the Excel spreadsheet and use the code that already exists there to produce the presentation? (I'd still need to figure out how to know when to break a line when using a non-monospaced font, as the users are currently doing that manually when they enter the data in the spreadsheet)
Jason Z:
If I set it to wrap, and I already have n lines, it would make n+1 or 2 lines on the slide, which is unacceptable.
Dennis:
That article looks very good, I should be able to glean something from it. Thanks!
Access has the capability to create downright beautiful reports. The problem is that it can't make a spreadsheet look better than Excel. You have to know when to use each tool.
Use Excel when you have spreadsheet-like formatting, need a lot of boxes and lines, or want to draw charts.
Use Access when you will output a report as a PDF. It's very useful for one-record-per-page detail reports, formatting where you need to position things very precisely, and where you need to embed subreports with related or unrelated data.
Think about the reports that would be nasty in Excel because you'd have to merge cells all over the place and do funny things with the placement and the layout would never work. That's where Access shines.
Joel, (your co-host here) did a thing about using access reports for shipping labels a few years back... maybe this could be a inspriation for you?
http://www.joelonsoftware.com/articles/HowToShipAnything.html
I have implemented Access reports which were 'pretty' enough. The downside is that it takes a lot of time and effort, and trial and error to produce the desired output.
You can definitely get there, but it requires the patience of a saint.
I guess it depends on what you mean by pretty. For example, I do not find it particularly difficult to produce say, reasonable graphs and tables with alternate line shading in Access. It is also possible to use MS Word and fill in bookmarks, or mail merge. If the present system uses VBA to create the PowerPoint presentation, perhaps much of it could be transferred to Access? Microsoft have an article on Access to Powerpoint: http://msdn.microsoft.com/en-us/library/aa159920(office.11).aspx
Finally, it is not impossible to build HTML output from Access.
We create multi-colored, conditionally formated, reports that are printed for the partner meeting each month of a publically traded corporation. They're real pretty.
I would suggest that the problem you're having is because the requirement to replicate the old method identically is an incredibly bad idea.
You're not using Excel any more.
You're using a different tool with different capabilities.
Thus, you will use different methods to get results.
Re-evaluate the original requirements to see if they still make sense (e.g., exactly why is PowerPoint involved at all? Can PowerPoint import from the Access report snapshot viewer? Can PowerPoint import from a PDF produced from an Access report?), or if they are too connected to the old tools, and then determine what is important and what isn't, and only then should you start designing your solution.
I personally would not try to re-invent the wheel here. If you already have an Excel sheet that has the formatting you want, just export the data from Access into Excel for the report. Now, if you didn't have the original Excel sheet to begin with, that would be a completely different story.
As for breaking lines with non-monospaced fonts, have you tried setting the cell format to wrap?
It sounds like the path of least resistance is to fill in the Excel spreadsheet. We have a contractor who does our Access stuff, and for the more complicated reports he uses Excel. I guess complicated == hard to make look good.
Rather than filling in the excel spreadsheet programmatically, you may want to use the external data features of Excel and Access. Generally I put a query on each tab, which of course may be hidden. An "update all" causes all the queries to be updated. Then summary tabs show the pretty results from all the individual queries.
For one particularly complex system, a bit of excel vba programmatically changed a query and then walked through the tabs updating each one.
Finally, rather than doing screen shots, Excel has a "copy cells as a image" copy that populates the copy buffer with a resizeable image. This could give you better looking results than a pure screenshot since a screenshot can have various deficiencies depending on pixel density.
Just an update:
After a few hours of work, I was able to get a nice report out of Access (almost an exact copy of the excel version). It wasn't as difficult as I thought, I just had to figure the correct mixture of out subreports and pagebreaks.
Working with the wordwrap features of Excel/Powerpoint were a dead end because there could only be a set number of lines per page, period; plus I was too lazy to nail down all the pagination with VBA code issues myself. Like Shelley says, Access shines at report generation.
The output ended up being a PDF (Using Adobe Acrobat Professional). The problem I have left is getting select pages of said PDF into Powerpoint without Powerpoint antialiasing the results for me and making the resulting slide's text fuzzy. I found a couple of articles on converting .snp output to .wmf, which sounds like the way to go on that front.