Open ebrelsford opened 2 years ago
To clarify, do we mean something specific by "all rendered feature data" as opposed to all feature data in the tiles?
Good point! Updated the name to be more open in that regard.
Here's it's also good to look at what https://stevage.github.io/vector-inspector vector inspector does well.
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 !
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:
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.
I can see how making a separate tool for viewing source data could be cumbersome if your development workflow is:
- edit in code editor
- build with build system
- 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.
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
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!
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.
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 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 👀
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.
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.
Oh duh, that makes sense. Thanks @kateler!
Maperture or not
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.
Without leaving this tool, I can look at the data in a tile, see what features and layers are being used and not.
Maputnik uses a library to do this but the opinion of the team is that it isn't good enough:
We should consider