You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For complex queries using a lot of controlled vocabulary combinations, it is imperative to use the services to extract data. Using the JSON REST service requires a lot of queries to get details of the objects. For some simpler use cases, it might be beneficial to use the CSV view, as this offers more data.
While the CSV representation does lose some information on 'kenmerkgroepen', it is sufficient for many use cases. We could quite easily implement a function that takes a query string, fetches the results in CSV and returns a dataframe.
The results of the CSV files are limited to 2000 results and are paginated using the link header. The CSV's do start with a variable length comment section without a comment character. Ideally this would be implemented at the source, but there is no standard comment character for CSV. The amount of lines that should be skipped can be determined by looking at the link headers, as the length varies because of the presence or absence of a previous/next link on the first/last page. This is however not considered a part of the API so there are no guarantees that this would be stable. It might be a (temporary) workaround until the comment character is implemented at the source.
For complex queries using a lot of controlled vocabulary combinations, it is imperative to use the services to extract data. Using the JSON REST service requires a lot of queries to get details of the objects. For some simpler use cases, it might be beneficial to use the CSV view, as this offers more data.
While the CSV representation does lose some information on 'kenmerkgroepen', it is sufficient for many use cases. We could quite easily implement a function that takes a query string, fetches the results in CSV and returns a dataframe.
The results of the CSV files are limited to 2000 results and are paginated using the link header. The CSV's do start with a variable length comment section without a comment character. Ideally this would be implemented at the source, but there is no standard comment character for CSV. The amount of lines that should be skipped can be determined by looking at the link headers, as the length varies because of the presence or absence of a previous/next link on the first/last page. This is however not considered a part of the API so there are no guarantees that this would be stable. It might be a (temporary) workaround until the comment character is implemented at the source.
@koenedaele, any thoughts on this?
The text was updated successfully, but these errors were encountered: