search

Terrastories / terrastories

Terrastories is a geostorytelling application for mapping, managing and sharing place-based stories.
https://terrastories.app
MIT License
316 stars 157 forks source link

[Discussion] Cloud based Terrastories #218

Closed kalimar closed 4 years ago

kalimar commented 5 years ago

I'm usually the one who would prefer to discuss things in a room but for the sake of everyone's time, perhaps we can discuss this asynchronously.

Does it make sense to have a version of terrastories that uses Mapbox.com (cloud based). What's the lift for maintaining that in addition to terrastories with tileserver GL?

There are times when we might want to use Mapbox.com rather than a local tile server (you are not in a remote location, faster setup of development environment, faster iteration for cartographers).

What are your thoughts?

kalimar commented 5 years ago

I'll start rambling here...

In general, this could be the primary repo where people can contribute to terrastories. It will require much less lift than using TileServer GL and will likely be less buggy.

We will need new documentation for how to contribute as a developer as well as a cartographer. The good news is that it will be easier for all.

Merging and syncing code is always a pain but we can figure it out. We'll definitely need to do it with some regularity since most of our real world cases still rely on the fully offline version.

Setting this up requires very little work, mostly just docker knowledge, and setting up map files on Mapbox.

kalimar commented 5 years ago

Another possibility we recently discussed was offering configuration options to switch between the two environments (the online versus the full offline)

rudokemper commented 5 years ago

I am all in favor of this idea and approach, thanks for bringing it up @kalimar. We needed Terrastories to work offline first and foremost because of the communities we work with in the Amazon, but there are so many use cases that don't have this specific need and can just work with online maps like on Mapbox.com. For some users, it may not even be necessary to have a custom map to begin with, and they could just use a standard online map like OSM. I had exactly this in mind when I described this issue.

I personally favor having everything in one codebase and being able to switch between different map locales in the configuration somewhere. But I don't know what that would entail from a technical point of view vs. other alternatives.

mirandawang commented 5 years ago

I like this idea very much. I think the offline-ability is a great feature to have for when the application is being used in the field, but it would be nice to be able to use Mapbox when developing. One of the main blockers for me personally has been the loading time of the app when developing. It can be really slow and frustrating.

New documentation will definitely be necessary. We can add this to the setup and/or contributing guidelines. I'm totally willing to volunteer for this part once we figure out how we're doin it!

I'm also a fan of keeping everything in a single repo, since we already have a mono repo I think it makes sense. It'll also save us some headaches of keeping everything in sync.

I'm not super familiar with Docker, but in my head i'm hoping the amount of work/solution won't be too crazy. We can set up a config option which can be set via command line params or a file change. The other work would entail actually connecting the Mapbox API pieces to the application based on a flag or some other variable. (This is the part that I'm slightly concerned about, see below.) Ideally when you restart the server Docker will then, instead of connecting tileserver + rails app, only connect the rails app. Then the Rails app will also have to know to try and hit the Mapbox API rather than tileserver.

One thing that I am potentially concerned about is how 1 to 1 the maps will be. If we develop everything based around Mapbox, will it still work with tileserver/the offline map? It would be nice if the APIs matched up so the only difference would be the URL that you are hitting. But I'm not sure if tileserver and Mapbox expect the same inputs and have the same endpoints.

If they don't have the same endpoints.... maybe we can create a map of them to exist as a constant somewhere in our files to make that switchover easier?

mirandawang commented 5 years ago

I realized that we would still be interacting with the same API... I believe. It's only where the map is hosted that will change. So I think we should be good on that front? And it could be as simple as changing which map server we are using?

robbkidd commented 5 years ago

One of the main blockers for me personally has been the loading time of the app when developing. It can be really slow and frustrating.

My impression is that the load time that causes the most pain is how the docker image for the rails service reruns dependency resolution (node modules and, I think, ruby gems) on every start. Solving that is a separate issue from letting the service be configured to pull tiles from a local tile server or from hosted MapBox.

mirandawang commented 5 years ago

Good point @robbkidd. I think the other pain point for me is code change refreshes take forever too when I have all the data loaded in, but that is probably because of how we fetch all the data on the first load. Which is still a separate issue.

Also wanted to say that I was mistaken in the first comment. The API should be 1:1 because we ARE using the Mapbox API already :) The only difference will be the actual map server.