Add web-based UI for Martin

[nyurik]

Add web-based UI for Martin

[tomeronen]

@nyurik, i think the primary focus of the ui should be on showcasing the server's catalog (your first point in Developer use cases). Integrating a Maputnik editor could be a nice functionality, but i think it might introduce unnecessary complexity to the UI. For DevOps needs i think a lot of people will have diffrent needs here, and martin might be part of a bigger existing architecture where these things are already taken care of. Maybe it could be cool to show live data of tiles for the current user session. For tile sources metrics i would add tile-size and total response time.

[jjcfrancisco]

Sounds like a great idea. The main martin page looks a bit bear at the moment. I would also include Maputnik.

[tomeronen]

@jjcfrancisco are you talking about the martin website or the page that will be received when you access the base path in a martin server?

[jjcfrancisco]

Apologies for the wording @tomeronen - I meant the base path in the server.

[tomeronen]

Its still in progress but what do you think about this direction?

Landing page

View TileJson (press on left layer action button)

Add layer to map (press on right action button)

with tile grid and popup position

Current rendered features by layer (taken from kepler.gl)

Things i started implementing but need to finish:

1. Style layer: fill style, line style opacity, line width, layer type.
2. Tiles metrics: How big are the tiles being sent, how long did they take to arrive.

[nyurik]

@tomeronen I absolutely love the work you are doing, thank you!

I have a few suggestions that might be helpful. Or not :)

• with tile grid and popup position - all good, we need a way to see overlay-ed tile grid. We may even want to have a "pinned" mode (e.g. with a pushpin) - where a user can zoom-in/out of the current view without actually "zooming" - i.e. make the current zoom bigger/smaller. Not certain how to do this or if its even that important.
• View TileJson - important to have, thx. I think it is easier to click outside of the popup to close it, than to click the x button.
• I am not fully convinced we need the landing page to view the catalog. I think the add layer to a map page is a better starting page (assuming we want to keep the focus on the served data, as oppose to the server statistics itself). The side bar would show all available sources.
• Maybe we could have a "top-level" tabs (instead of the map occupying the entire screen space. If we do, we can add a few tabs like a sprite visualizer (clicking a sprite shows its image), fonts (probably some font statistics(?), and another tab could be server performance metrics

[tomeronen]

@nyurik few questions:

1. "where a user can zoom-in/out of the current view without actually "zooming" - i.e. make the current zoom bigger/smaller." do you mean bring data for a diffrent zoom then what is actually used in the map? for example the map is set on zoom 8 and fill it with data using zoom 12? if yes this should be really easy.
2. ill add close by click outside 👍
3. Good idea about the top tabs :) ill add it as well. maybe there could be four tabs: catalog viewer, data viewer, statistics and style editor.

Regarding the server statics in the current use case i am using we have k8s cluster with 2 instances of martin running behind a k8s service. And we gather the statics through a proxy server. So adding server metrics to the ui will show partial metrics of a single service. How uncommon do you think this use is?

[nyurik]

1. if i am on zoom 10, it may show certain data. That data may be too small on the screen, yet i cannot "zoom in" because it will be replaced by the data from zoom 11. Instead, I want to keep looking at zoom 10, but make everything just bigger to make it easier to examine. update Maybe we can add a slider to represent "visual zoom" as oppose to "data zoom" which can continue be represented with a big ➕ and ➖ icons? Or we could make two sliders side by side?

2. i was about to say that I just on-boarded Maputnik style editor - so it makes perfect sense to include that as well :) - see #852

3. server statistics is a tricky one - you are right that most, even small, places would use some load balanced redundancy like k8s. That said, k8s only provides overall service-level statistics like the number of requests and pod memory usage. Any kind of debugging or in-depth info would not be as easily available - e.g. seeing the number of requests PER source or PER zoom would require considerable additional work with datadog or elasticsearch or .... Moreover, k8s stats would not have any other breakdowns, like cache use. On top of it, one thing that none of the logging platforms offer (AFAIK) is to see the map hotspots - visualize which tiles get requested the most. For that, we may need to implement additional per source per tile tracking feature (not trivial, but doable)

[tomeronen]

Hey @nyurik i am a bit stuck, and will be happy for some help. Based on #852, Im trying to use actix_web_static_files to build and serve the client code. I think once there is the base to build and serve static files, we can start building the ui in small PR's each time. Im new to rust and trying to learn as i go. Could you help me with setting the base to building the client code and serving it?

[Youssef-Harby]

Hello @tomeronen , interesting work! I can offer assistance with this project as I am currently learning Rust and have some experience with Actix as well as developing build pipelines.

I am a bit confused about what you are trying to achieve with issue #852 , Are you aiming to serve a pre-built embedded Maputnik in Martin, or are you looking to build a new React UI and then create a URL endpoint, for example, /explore, for serving the new UI you are developing in React?

[tomeronen]

@Youssef-Harby what i had in mind is creating a new project, taking the Maputnik code and try to integrate it as part of the total ui. As talked above, we can have three tabs. One for style edit (Maputnik), one for showcasing the data, and one for service metrics.

[nyurik]

@tomeronen and @Youssef-Harby thanks so much for working on this! I pushed some changed to the @tomeronen 's repo, and also merged in the main branch to keep the code up to date. Also, I addapted a few changed by @Youssef-Harby such as removing the tsc compiler call - i think it might be a bug -- i saw some errors in the console.

In any case - it seems to be working now -- you can use just run (assuming you have just installed), and it will compile and run Martin, and also include the compiled js code (it will execute npm run build during Martin build).

So current issues:

• it takes a bit of time to compile Martin - and the js code is included statically, so a bit difficult to rapidly develop because Martin has to be recompiled after each js change. I have some ideas on how to make it dynamic, but will have to do it another day
• please see if the npm run build does the right thing now
• currently, the index is served from /, and the assets are coming from /assets -- which is not good because there may be a tile source called asserts. We should probably make it access /_/assets/... instead.
• all tile source access goes via localhost:3000//src/... -- note the two // in it. Should probably be fixed?