Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss how to handle Onroerend Erfgoed data sets accessed through json API #2

Open
maarten-vermeyen opened this issue Mar 5, 2024 · 0 comments
Labels
question Further information is requested

Comments

@maarten-vermeyen
Copy link
Contributor

For the simple features datasets, we do very little processing on the end result on top of st_read(). When accessing datasets from non geographic authentic datasources this is more difficult. The API's often return complex json data structures. Within the context of roeference, we might want to simplify this datastructure as much as possible. For example:

df <- request('https://besluiten.onroerenderfgoed.be/besluiten') |>
        req_headers(Accept = 'application/json') |>
        req_url_query(per_pagina=50) |>
        req_throttle(30/60) |>
        req_perform_iterative(iterate_with_link_url(rel = "next"), max_reqs = 1000) |>
        resps_data(\(resp) resp_body_json(resp, simplifyDataFrame=TRUE)) 

Would return a simplified dataframe. Each besluit is a row. Some rows may contain vectors or (nested) lists for certain variables. While this might be ideal for some use cases, it offers little control to the end user. However, more complex use cases where the user might want to parse json themselves might be out of scope of roeference.

In addition, we need to determine sensible throttle and per_page values to avoid performance issues on the server end.

@maarten-vermeyen maarten-vermeyen added the question Further information is requested label Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant