stamen / maperture

https://stamen.github.io/maperture/
MIT License
38 stars 11 forks source link

Discussion: Consider adding a debug mode to show all data in tiles #44

Open ebrelsford opened 2 years ago

ebrelsford commented 2 years ago

Maputnik uses a library to do this but the opinion of the team is that it isn't good enough:

image

We should consider

almccon commented 2 years ago

To clarify, do we mean something specific by "all rendered feature data" as opposed to all feature data in the tiles?

ebrelsford commented 2 years ago

Good point! Updated the name to be more open in that regard.

almccon commented 2 years ago

Here's it's also good to look at what https://stevage.github.io/vector-inspector vector inspector does well.

aparlato commented 2 years ago

I'm doing some thinking about this now and would like to get a better sense of where the inspect mode in Maputnik fails so that we know how we might want this to work or whether something closer to https://github.com/stamen/map-compare/issues/43 might serve us better in this tool.

I'd also like to check in on the use case here: Do we think we'll use this mostly to compare a style to its own debug style to see how data is filtered or are we thinking we'd compare the debug styles of two separate styles to get a sense of how the data compares?

Distinguishing between features that appear on the map and those filtered out by the style

One thing to consider here is that, when looking at all source layers and all style layers here, it's likely that this view will be overwhelming. In Maputnik, we have the advantage of being able to show filtered vs unfiltered features/data based on a single selected layer. This is something we don't have in this compare tool. And it may result in this tool trying to do too much if we allow selecting a style or source layer.

Another potential issue with using the map style as the basis of our debug style is the number of sources. If we're concerned mostly with seeing two sources next to each other to see how they compare, maybe the right approach is to allow a dropdown option to insert a link to a tile json or pbf similar to the Vector inspector to create a style that isn't connected to a real map style that represents that data.

Lastly, regardless of path forward here, my inclination is to see how far we can get with a more scoped solution like https://github.com/stamen/map-compare/issues/43 before trying to implement this.

Curious to hear your thoughts @ebrelsford @almccon !

ebrelsford commented 2 years ago

I'd also like to check in on the use case here: Do we think we'll use this mostly to compare a style to its own debug style to see how data is filtered or are we thinking we'd compare the debug styles of two separate styles to get a sense of how the data compares?

I'm also curious about this. I was mostly thinking the former (compare the rendered style to the source data to see what else is available in that source) but I could see the latter being interesting too.

If we think about this tool as part of a replacement for Maptunik (editing happens in a code editor, viewing happens in this tool), then I can see the argument for bringing more of the viewing and analysis features from Maptunik into this tool. I can see how making a separate tool for viewing source data could be cumbersome if your development workflow is:

  1. edit in code editor
  2. build with build system
  3. view in this tool

One thing to consider here is that, when looking at all source layers and all style layers here, it's likely that this view will be overwhelming.

Agreed. And if we were to build a UI for doing layer selection, would that be useful in the tool generally or would it only be useful here? And at that point is this better off in its own tool?

If we're concerned mostly with seeing two sources next to each other to see how they compare, maybe the right approach is to allow a dropdown option to insert a link to a tile json or pbf similar to the Vector inspector to create a style that isn't connected to a real map style that represents that data.

I think this might be useful either way in terms of tile dev. Being able to compare the current tile source with a tile or two of dev tiles would be handy...

Lastly, regardless of path forward here, my inclination is to see how far we can get with a more scoped solution like #43 before trying to implement this.

The sounds good to me, let's start with #43.

aparlato commented 2 years ago

I can see how making a separate tool for viewing source data could be cumbersome if your development workflow is:

  1. edit in code editor
  2. build with build system
  3. view in this tool

Just to throw another idea out here if this is a blocker to creating a separate tool: In client projects, we could make this less cumbersome if we wanted (with a little more work) by threading tools together. If we had a separate tool for this functionality, structured similarly, we might be able to add a custom link between tools right in the client specific repo's HTML file to switch between them without restarting a server. There are likely some issues to work out here and we'd have to force the link to open a new tab so that we don't change the URL that persists state though.

kelsey-taylor commented 1 year ago

I'm doing some thinking about this now and would like to get a better sense of where the inspect mode in Maputnik fails so that we know how we might want this to work or whether something closer to https://github.com/stamen/maperture/issues/43 might serve us better in this tool.

What fails for me with the data view mode in Maputnik is that you only see the data for features in whichever layer you have selected. Being able to see everything would be so much more useful in most cases

Distinguishing between features that appear on the map and those filtered out by the style

Mapbox Studio does a really nice job at this that we could emulate

RossThorn commented 1 year ago

Just to weigh in with nothing new, the number one use case to me is just seeing the data in the tiles. It's really helpful to see the data and all properties that we can use when creating styles. The actual "what's rendering" or "what's being filtered out" feature seems like it could be cool too!

Another potential use would be a focused tile view where I can look at the data in just one or a couple tiles and see all the features listed or grouped by tags/sources in a slightly different UI than something listing all of the layers. This aids in helping troubleshoot specific areas if something is appearing buggy in a certain area. So a focused tile view and a focused data view for those specific tiles would be helpful.

What fails for me with the data view mode in Maputnik is that you only see the data for features in whichever layer you have selected. Being able to see everything would be so much more useful in most cases

@kelsey-taylor I thought this was the case as well, but it doesn't appear to be that way for all styles? I'm kinda just finding this out now. I've only really used Maputnik for our stylesheets that we create for clients and it's true that you can only see the data in the layers you have selected. But if I look at the OSM Liberty map style (one of the default selections in Maputnik), I can see everything! image

for context, here's the same area above just loading one of our own style jsons. Kelsey is right in that it's blank unless I select a layer, then it only shows that specific layer. image

So maybe Maputnik can be a good candidate and we need to figure out why our style jsons don't show every layer when loaded into the editor, and if there's anything we could do on our json generation or could do in our Maputnik fork to better suit tile inspection with this method.

Maybe one or all of you already know why that is 🤷

kelsey-taylor commented 1 year ago

@kelsey-taylor I thought this was the case as well, but it doesn't appear to be that way for all styles?

I was thinking the same thing! I don't remember it being so limiting when I worked on a set of styles with their own tiles last year, but we had a separate fork with some changes that I assumed explained the difference. Not sure what's going on there 👀

ebrelsford commented 1 year ago

I dug into this a little by making the simplest version of one of our styles and it still didn't work. I imagine there's some debugging we could do around this part of Maputnik if we decided that was a possible avenue. Most of the work there is done by mapbox-gl-inspect.

kateler commented 1 year ago

Unlurking to shed some light on this. The difference is whether there is a tile.json file for the source, or if it points to tiles directly. A tile.json contains the usual source info plus a basic schema for the tiles, telling the inspect function things like what layers are present, data types, and what kind of geometry is included.

Here's the OMT file, which is especially detailed. I created tile.json files at Amazon that were simpler and didn't include all possible values, and those worked fine too.

ebrelsford commented 1 year ago

Oh duh, that makes sense. Thanks @kateler!

dnomadb commented 1 year ago

Related: https://github.com/stamen/carto-tools/issues/16

mulloverit commented 1 year ago

Grooming discussion

Maperture or not

User story

As a user of Maperture, I want to be able to understand how tile data correlates to the style that I'm working on. The ability to do this in Maperture would be much less cumbersome than current solutions (which force us to jump between applications) and would speed up our style development work. This is the kind of tooling that is helpful when styling a feature for the first time in order to understand the frequency/density of that feature. This would also help find feature/tagging anomalies in tiles.

Acceptance criteria

Without leaving this tool, I can look at the data in a tile, see what features and layers are being used and not.

Client impacts