right now the download map, on load for a specific collection, hits the carto api in an iterative fashion to build the area download layers. this way it functions creates a longer initial map load time and relies on carto (which has caused issues in the past from security and api request limit standpoints). we should update the download map to satisfy...
utilize our mapserver instance for the download areas layers in order to drop carto and have better control on the retrieval of our layers. may help with performance as well.
reconfigure the general load process of download map layers. implementing our mapserver may present an obvious solution to the iteration during the switch but one other floated option is to do the retrieval on app load (rather than map load) and keep the contents in the store. then on map load, pull from the store and query down for adding the layer into the map.
update the geofilter map process for mapserver. right now, it works by querying data directly in postgis calls so we'd probably have to hit the mapserver rds directly rather than the mapserver 'services'/mapfiles. the mapserver rds is in a private database subnet... a new api endpoint to perform these queries will most likely be in order
right now the download map, on load for a specific collection, hits the carto api in an iterative fashion to build the area download layers. this way it functions creates a longer initial map load time and relies on carto (which has caused issues in the past from security and api request limit standpoints). we should update the download map to satisfy...