For storing and querying geo data use knex-postgis. One typical request would be "find all professionals within a bounding box". See feathers discussion feathersjs/feathers#3299
Apply this to professionals page in admin app and search page in frontend app.
Problem: paging would apply in the query (default max is 50 items) which is not ok for a map. Then we may consider storing geometries in a table that can be used by a Martin tile server. The filtering by bounding box would be performed by Martin. The filtering on other criteria (type of professional for instance) would then happen in the layer definition (do not paint features with property xxx) UPDATE: see comment about Martin's function sources. This would allow to render many points as clusters for the lower zoom levels. This could allow to display entities of different types in the same map (ex professionals, buildings, natural resources), something that would normally require several feathers queries.
backend:
add knex-postgis dependency and decorate knex object with it (see knex-postgis doc)
migrate professional: split areaDelivery column in radius (number) and coordinates (geometry Point, good luck with TypeBox)
seed professional: populate accordingly with Point geometry
add Martin to the docker compose, connected to the postgis database, with appropriate traefik routing for Martin (ex /martin)
admin:
professionals page: refactor add/edit professional with the new radius/coordinates columns
frontend:
search page:
refactor the map component so that it refers to the vector sources of Martin, setup layers with cluster rendering popup etc on professionals, dynamically modify layer paint properties according to search criteria (professional type selection for instance)
refactor table rendering with radius column
professional page: update with radius and coordinates
For storing and querying geo data use knex-postgis. One typical request would be "find all professionals within a bounding box". See feathers discussion feathersjs/feathers#3299
Apply this to professionals page in admin app and search page in frontend app.
Problem: paging would apply in the query (default max is 50 items) which is not ok for a map. Then we may consider storing geometries in a table that can be used by a Martin tile server. The filtering by bounding box would be performed by Martin. The filtering on other criteria (type of professional for instance) would then happen in the layer definition (do not paint features with property xxx) UPDATE: see comment about Martin's function sources. This would allow to render many points as clusters for the lower zoom levels. This could allow to display entities of different types in the same map (ex professionals, buildings, natural resources), something that would normally require several feathers queries.
backend:
/martin
)admin:
frontend: