Thanks for the notes, everyone. I think the next release will include some nice updates.
I’ll be responding to a few posts with this single reply. It may work out that I partially reply to one person, and further relevant details on the same note appear later on in this message. So, read the whole post. 
Yeah, and I definitely have some ways to improve it - it just wasn’t the focus of this test. Its main purpose was to show how this new test setup allows for a bit more interaction (this would open the door to a “show all” option for cities within a Region, for example). The more I see/use it, though, the more I really want to clean it up so it can be added to the Cities - CityStrides page.
In cases where you’re viewing cities across region/country borders, I would advise not enabling any filter.
Ah, yeah, I need to do some more work to ensure the city border layer gets placed below all other interactive layers.
Thanks! The next release fixes that up.
Can you expand on this? I’m unable to cause breakage by navigating around…
I’ll have to test this out … I’m unsure how things will behave when city borders are shared with adjacent cities. Maybe I can do something like with Node Hunter - where if you click a node it will display a popup that lists all the related streets.
Changing it from clicking within the city border to on the city border would also remove the need for the hover popup, which really gets in the way.
Yeah, that’s the goal … ultimately, I want this functionality available on every map view throughout the site. Kind of like how you can use Node Hunter everywhere. I just need to test things in an isolated page so I don’t ruin everyone’s experience during the build process.
I’m pretty sure that it’s due to the ordering of the underlying data. Some of the nested cities are returned before the parent city and some are returned after … Resulting in the nested city being “on top” in some places and “below” in others … I think the fix here is to ignore nested cities for this feature & rely on the “Nested Cities” tab if you’re trying to navigate into one of those.
Yeah, I also noticed this in an image someone recently shared on Twitter. 
I think color choice is one of the hardest things I have to do while building CityStrides. 
Alright! 
time!
The existing city borders that are present on the Cities list page as well as each individual city page… Those are GeoJSON files that are cached by an external service. Whenever you click the show button or visit the city page, a request for the file is sent & it may or may not return the cached data. If it does return cached data, that does not count as external bandwidth → lower 
The data for this beta page are vector tiles. The caching that’s available for this data is different from what’s available with those GeoJSON files. It can cache in the server, which does not lower & each tile can be cached in the browser, which does lower … That first page load, for a new visitor, transfers about 1mb 
but if you reload the page, it’s 0mb because the browser still has it on disk 
(I could implement a thing where you click a button and it gets the Northeast/Northwest/Southeast/Southwest coordinates of your view & asks the server for cities that are “in” that space & in turn requests each GeoJSON file for those cities 
but there are a number of problems with this approach, like how many cities are in view.)
That’s something I’m still figuring out. I also don’t have any automation in place to keep borders updated if they change in OSM. I probably wouldn’t need to regenerate the data behind this beta view unless a city’s border changed somewhere in the world (e.g. two areas being merged into one). The total build time for this is only ~30 minutes, so that’s fine.
who knows.