zoran995
commented
3 days ago Hi @BenVanzino, thanks for raising the issue. For large vector datasets, the recommended approach would be using vector tiles as they are primarily designed for that. In the long run, it would be definitely nice to explore this possibility but not sure how huge a priority it is to the team right now. Currently, TerriaJS loads all data at once and then converts it to vector tiles on the fly, which should prevent performance issues with rendering. If you are experiencing any problems, please let us know.
Could you share some examples of the solutions you are referring to? If you're interested in exploring this further, we'd be happy to review a pull request.
BenVanzino
AnaBelgun
The current Esri Feature and WFS datasource implementations are not using BBOX extent limits in their API interactions. This is resulting in an unfiltered extent for the web service being requested for every interaction. This is not best practice for working with these kinds of spatial web services and leads to overload and timeout, failure to draw or general poor performance for the user.
Could these datasource interactions with terria use the map state bounding box to filter the interactions with the generated service requests as a fundamental improvement to how they work?
This is how best practice implementations are designed in spatial web applications and allows large feature count API interactions to be robust and performant. These requests are also tiled (3x3 or 4x4) extending slightly beyond current screen extent in many "good" implementations that i've seen.
This issue is repeatedly coming up with client use cases and interactions for our product and jeopardises our decision and use of TerriaJS as the foundation.