Skip to content

Request for more info #4

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

Closed
jchudge opened this issue Jan 25, 2023 · 2 comments
Closed

Request for more info #4

jchudge opened this issue Jan 25, 2023 · 2 comments

Comments

@jchudge
Copy link

jchudge commented Jan 25, 2023

  1. Are you able to provide a diagram or an overview of the data schema for Soundscape (including that which was handled on the phone and that which was handled by the services…and the underlying data structure in support of this)
  2. Peak active users at any given time
  3. Any other telemetry you can share which would be useful
@AdamGlass
Copy link

Regarding #2, and #3

  • I can provide information that might inform anybody bringing up the service now. The current production service after the announcement still has a few hundred unique users a day with about 5 times that for a 7 day week. The app has substantial caching functionality so that limits some services impact at least in the production configuration.
  • Unfortunately I can't provide telemetry. The user agreed to provide that telemetry to Microsoft and not a 3rd party. There have been some past research projects that used Soundscape -- perhaps they've published something that would help.

I'll address the #1 question separately.

@AdamGlass
Copy link

Sorry for the late reply.

I can't provide a direct schema but i can provide a description of the division of storage/state in the open source version. The iOS client stores markers , routes, and all user preferences. It also stores cached OSM data as retrieved from the service. This is all stored in a realm database.

In contrast, the service retrieves OSM data from one of the OSM mirrors, processes it using IMPOSM3 -- storing it in a Postgres database. Upon tile request to the service (in sources as 'gentile.py', this service uses a PostGIS sql query to retrieve the data that applies to that tile and transforms it to GeoJSON.

There are no acccounts, no PII storage, no concept of individual users as seen by the core service, and no sharing via a centralized service.

There was an additional web service that was used for some web authoring scenarios but consuming one of those routes, just inserted it into the local storage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants