Running without cloud services

[steinbro]

(Continuation to my comment in #8, but thought this deserved its own thread)

What if one changed the tile ingestion processes to load into SQLite rather than Postgres?

Assuming that the soundscape_tile function in tilefunc.sql isn't too Postgres-specific, this would generate an equivalent database as a file that could be loaded onto the device, presumably limited to a specific region to keep it relatively small. Using something like SpatiaLite would provide GeoJSON capabilities in SQLite.

The client would then make local SQL queries rather than tile server API calls. Is there anything else that would need to be done?

[steinbro]

(Thanks, BTW, for your quick and helpful responses on #8!)

[AdamGlass]

Well if you re-encoded the OSM PBF file -- all 68Gb compressed of it into a SQllite database and SQLlite didn't puke, sure you could it all locally.

More seriously, realistically you don't want to have that large a percentage of the map on your device, so you're likely still building some service to fetch subsets -- either pre-computed as SQLlite databases or in raw PBF form. Lets say for laughs that you pull your PBF files from here http://download.geofabrik.de/ where they kinda subset the PBF files by region. You still then need to process that PBF file which isn't super trivial to create a more useful representation -- all the tools for doing that are frankly linux CLI tools. Maybe if you go this path, you can host pre-computed SQL database files for each region on a storage account. In one sense, you're trying to make it work more like a bike computer with a downloaded map. How effective that is is really dependent on POI data you need to be able to retrieve from, how you pre-process that data to make it consumable, etc.

There is a separate headache here that the app itself actually uses a different database engine called Realm. The engineering team went with it over SQLite but I believe there was some later regret about that decision. Realm had a bunch of IOS specific magic i think that maybe didn't pay off. For this application you likely need Spatiallite which is an extension to SQLlite for GIS indexing, etc.

I continue to be surprised the extent to which folks are scared off by the service part. Is this because this is the only component that would actually cost $ to run vs. the app itself which is a basically a developer account fee per year. I really think you could cut the costs of the services with thoughtful engineering.

[steinbro]

Yes, the bike computer-type setup is what I had in mind. The geofabrik.de site hosts maps by state, which are all 1GB or less. This seemed reasonable to store on a device, even if it blew up by an order of magnitude when encoded less efficiently.

That said, I fully acknowledge my suggestion is inferior in many ways to the current setup, for the reasons you identify. Based on your answers, the services approach seems very much the right engineering decision, especially seeing as the tile server is just a couple hundred lines of Python.

I think one reason for the aversion to some other entity picking up the hosting responsibilities stems from users wanting to avoid the situation we're in now, where the app will cease to function based on someone else's business decision. Don't get me wrong -- we're super grateful that Microsoft decided to open-source the app. But there's a lot of value in making an app self-sufficient in the sense that, as long as the device it's installed on still works, it will operate indefinitely. Especially with assistive devices, users tend to cling to tech that work for them longer than any company could reasonably support them.

[bramd]

I'm not adverse to running/hosting services, but some work needs to be done to get to a turnkey/working solution since some deployment bits are missing and/or Azure specific. Frankly, if cost is the issue, you could run this on a cheap dedicated server (no cloud VM, since 1 TB of block storage would be expensive) for €40-80/month either with or without a Kubernetes cluster. Not redundant, but workable for sure with a fixed cost and no cloud bill surprises. That said, I think mobile app developers would be less comfortable providing this infrastructure, where devops/backend developers would be more uncomfortable working on iOS code. I would seriously be interested in setting up some kind of coordination between interested parties willing to continue development of Soundscape to get things moving and share this kind of infra between possible forks.

Maybe we should open a new discussion/issue for that.

[AdamGlass]

switching to business hat for a second:

Sure you could run a single service for multiple forks of the client app. Multiple forks that we don't seem to actually have today. However, you really need to tie the client to the service to avoid somebody owning only the expense part of the story. I've run these kind of "I'm running this service for free" things in the past for organizations and it adds up and there really isn't a good way back since everyone is used to not paying for the infrastructure.

I have no real doubt that someone could bring the service up. What I haven't see from my vantage point is:

• Someone stepping up to build/fix/release the client
• Someone who will commit to $X dollars a year to run a service -- even with Bram's minimal setup

I feel obligated also to point to the calendar -> Microsoft turns the service off on 6/30.

Perhaps i'm just not in the know. @Jarnail Chudge @.> @Jarnail Chudge @.>

On Sat, Apr 15, 2023 at 5:04 AM Bram Duvigneau @.***> wrote:

I'm not adverse to running/hosting services, but some work needs to be done to get to a turnkey/working solution since some deployment bits are missing and/or Azure specific. Frankly, if cost is the issue, you could run this on a cheap dedicated server (no cloud VM, since 1 TB of block storage would be expensive) for €40-80/month either with or without a Kubernetes cluster. Not redundant, but workable for sure with a fixed cost and no cloud bill surprises. That said, I think mobile app developers would be less comfortable providing this infrastructure, where devops/backend developers would be more uncomfortable working on iOS code. I would seriously be interested in setting up some kind of coordination between interested parties willing to continue development of Soundscape to get things moving and share this kind of infra between possible forks.

Maybe we should open a new discussion/issue for that.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/soundscape/issues/12#issuecomment-1509751886, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUP64FC52FIHYYJDDTDMJDXBKFGDANCNFSM6AAAAAAW47TX2Y . You are receiving this because you commented.Message ID: @.***>

[steinbro]

Do you know if there have been any discussions with blind-related nonprofit organizations that might be interested in adopting the app? It does seem like there are a few of us developers who'd volunteer to get the app packaged and the services provisioned if such an org needed the help. But even putting costs aside, it would take a pretty dedicated individual who'd want to personally take on an ongoing long-term commitment like hosting.

[bramd]

@AdamGlass Totally agree with your points. Client is the first priority, but I wanted to get an idea of all the parts involved in a fully working setup. Also, having ideas about the TCO and work needed is good to have when talking to interested parties.

I can't post specifics in public here, but I'm getting in touch with some blindness organizations and innovation funds to see if there is any interest in picking this project up. I have been a happy Soundscape user for years and would like to see it continued in any way.

[steinbro]

Update: I've put together a backend that forwards queries to an Overpass server: https://github.com/steinbro/overscape. I've confirmed it works with the app in the simulator.

My goal was to replace the incomplete data pipeline with something standard, where external expertise and resources already exist and could be leveraged. I'm hoping this will at least be of significant value to iOS developers who would be intimidated by setting up their own cloud infrastructure. Using a public Overpass server, they'll now have access to global data without an ingestion process or storage requirements.

As AdamGlass noted in https://github.com/microsoft/soundscape/issues/8#issuecomment-1499116044, public servers may not be the long-term solution for the general user base. But some of the open instances do seem to have very friendly terms, e.g. https://overpass.kumi.systems/ -- they may be quite happy to support a good cause.

[AdamGlass]

There are a lot of problems down this path. Kumi is not providing a real SLA and could easily be overwhelmed if the client's make individual accesses which gives each their own quota. They could also bail out without notice.

I think its cute for prototyping but I'd be very uncomfortable shipping anything in this configuration unless you are hosting that overpass service and are thus on the hook for the cost.

[steinbro]

@AdamGlass, I hear you, and it's not my favorite idea either. Running our own Overpass server could work (you can apparently pay Geofabrik to provide this service for you). But, if we had the resources to provision our own infrastructure, I imagine sticking with PostGIS would perform better, and would certainly have a more familiar query syntax.

Thank you for bearing with my running down some admittedly suboptimal ideas. Having now experimented with PostGIS and Overpass as data sources, I'm going to close this issue as "not preferable."

[RDMurray]

Hi @steinbro Thanks for your work on the docker compose branch and overscape. I don't think you should necessarily give up on the idea yet. Overscape is certainly easier to get up and running with, and it requires far less resources. If nothing else it is perfect for use while developing the client.

[steinbro]

@RDMurray Glad you've found it helpful. And yes, the reservations were just about using this in production, not as a development tool.

I see you're working on a branch to compile for iPhone without a developer account. I didn't know that was possible, but am very curious what needed to be done to get that working (assuming it is).

[Oliver2213]

I cloned and tested @RDMurray's branch and got it to build.
I'm not an iOS dev (though certainly looking into it now to help with this); from what I can tell, the specific capabilities that require an apple developer account were removed (push notifications, cloud key value storage and associated domains), the signing certificate type was set to "apple development" instead of "iOS development", and XCode manages certificates and app IDs.
It came up with onboarding just fine when I sent it to my iPhone, though of course it isn't actually functioning fully since I haven't tried to bring up its back-end services yet.
I'm not sure what cloud K/V is used for yet (maybe for user prefs and flags like if they've completed onboarding), nor am I sure what it needs push notifications for.
@RDMurray this is an awesome step; thank you. I fiddled around with this a few days ago and didn't get nearly so far in removing capabilities and getting it building. I tried some of this, but as I mentioned I'm new and poking around, so never got it quite right.

[RDMurray]

@steinbro and @Oliver2213 It does work with the capabilities removed. I haven't looked into what they are used for but I haven't found anything so far that doesn't work, apart from search which I think was powered by Bing in the official app.

There's an overscape instance at soundscape.mur.org.uk. Feel free to use it for testing. It's on my home server behind a cloudflare tunnel so don't be surprised if it isn't up all the time.

[RDMurray]

I just pushed to that branch, it will get beyond onboarding without crashing now.

[bramd]

FYI, I also have a fork that has a mostly working client that can be compiled with latest Mac OS and Xcode. Search is not working, but I left the iCloud key/value store and notifications stuff in place. I don't expect notifications to work at the moment, but the cloud keys/values do work. This is used to sync markers and routes (and probably other things as well?) between the user's devices. I run a server based on the imposm configuration and Python HTTP API provided in the open source code at https://soundscape.bramd.nl/. This has only map data for The Netherlands for now and performance is not the greatest due to lacking disk i/o. Feel free to use it for testing/development.

[Oliver2213]

I've forked this repo and pulled in @steinbro and @RDMurray's changes; I intend to start a free organization and move it there, then invite people and admin them (so I'm not the only one who can invite people), so we can hopefully collaborate a little more easily. Would anyone join this? What should we call it? We're making progress, but imho we need to start building a community around this, even though it feels early days and (slightly) silly at this early a point in the process. A discord / slack / telegram as well maybe. Thoughts?

[steinbro]

@Oliver2213 I agree that if we now have multiple individual forks with worthy changes, a new centralized repo would be merited. And a place for conversations would be welcome -- outside the issues in this repo, I haven't seen any discussions among individuals hacking on the code, save for a thread or two on AppleVis.

It's not clear what to do with the name, per #13. I'll toss out a first idea: Ambusonic, a play on ambisonic (a type of 3D sound rendering) and the prefix ambu- (meaning to walk/move).

[Oliver2213]

Naming things is truly the hardest problem! 😄 I like ambusonic, though it Another one I thought of is hedge maze. Sound -> sonic -> hedgehogs! -> mazes, walking around and paths. So hedgemaze! 😆

[steinbro]

@bramd When you say iCloud key/value store is working, I assume you either have a paid iOS developer account, or are just using the simulator? I think if you try to provision a build for a physical device with a free developer account as RDMurray was, you'd run into problems trying to use certain capabilities, specifically the ones missing from the last column of this table in Apple's documentation: https://developer.apple.com/help/account/reference/supported-capabilities-ios#//apple_ref/doc/uid/TP40012582-CH38-SW1

@Oliver2213 hedgemaze is pithy, but might sound too much like a game, and the leap from sound to hedgehog might not be obvious to everyone. Another idea: Soundpost, kind of like an audio signpost, also "post" meaning "after" (like Postgres was a successor to an earlier database called INGRES). It's also a real word (part of a violin).

[Oliver2213]

Hmm. What about openscape, as a good-enough for now placeholder? It's close enough that people looking night make the connection.
Edit: name is taken here on Github.

[steinbro]

Heh, well, hedgemaze and soundpost are taken as usernames, too.

To me, a long-term name for a new fork isn't a huge concern at the moment. This repo's issue section has already been serving as a venue for discussions, though naming is probably something that belongs in a new thread.