Open jeffreyameyer opened 1 year ago
Cartographic comps: Google Maps: https://www.google.com/maps/@37.5398688,-77.4840136,16z?entry=ttu Mapbox Streets: https://api.mapbox.com/styles/v1/mapbox/streets-v12.html?title=true&access_token=pk.eyJ1IjoibWFwYm94IiwiYSI6ImNpejY4M29iazA2Z2gycXA4N2pmbDZmangifQ.-g_vE53SD2WrJ6tFX7QHmA#15/37.53922/-77.47786 Bing Maps: https://www.bing.com/maps?cp=37.539235%7E-77.476144&lvl=15.0 OpenStreetMap: https://www.openstreetmap.org/#map=16/37.5382/-77.4782 MapTiler: https://www.maptiler.com/maps/#style=streets-v2&mode=2d&position=15/37.53963/-77.47871
One of the reasons we (and others) do not have boundaries around park lands is because lines tend to add lots of visual clutter to maps. If we were to add boundary lines to parks, the contrast between the park fills and lines should be very minimal to cut down on clutter as much as possible.
We did this once for a base map that we created that was specifically for park lands, and not a general base map. https://www.parkinfo.org/
Yeah... that's why I said I couldn't find any good comps - I don't think this is something any modern web maps do well, but that a black and white line map might do better (my quick search couldn't find any!).
I agree that the distinction should be subtle - what was done with the parkinfo.org site looks right on, in terms of approach!
I agree that the ParkInfo map does a good job of delineating the boundaries without calling too much attention to them. OSM Americana also puts a border around parks, which also makes it possible (and forces us) to show parts of the park that extend out into water.
Ok - sounds like we're in agreement on a) utility and b) possible treatments?
If so, let's turn over to @vknoppkewetzel & @tsinn for carto options?
I have a quick question for context on why we want to add border to parks on OHM. This helps me in understanding design goals around this (designing with purpose): why do we want to highlight park boundaries for OHM?
In the above examples Tim gave (and in many print maps), park areas tend to not have boundaries shown due to the clutter Tim mentioned, but also that the park boundaries and delineations tend not to be relevant for that specific map's intended purpose so the visual clutter is not only visual clutter, but also provides a sort of "data clutter" as well. Many maps do not show the boundaries to highlight the bigger green space area that is connected (as park names and variances also often exist simply due to variances in ownership and management, which is relevant to maps like Park Info above and PADUS - although it looks like even PADUS doesn't immediately show the lines)
Tim and I definitely can come up with some options here but I guess I want to step back and ask the question around the "why" to make sure the design choices I make, make sense (or, to make sure if we should actually add park boundaries at all - since it does add visual clutter, even if subtle)
I think the key issue is just to understand a bit more about the actual history of the areas. In the example listed above, these are very different parks that just happen to be adjacent. If you look at Maymont + Byrd as one unified area, it's hard to tell where one starts and the other ends or if Maymont was just an expansion of Byrd or a different part of Byrd, but it's neither.
In general, I agree with the concerns about visual clutter, but in rare cases like this, I think this will help.
What if we didn't put borders on all park areas, but just ones with a particular tag? (I know, this is tagging for the renderer, but this might be helpful for the reasons identified above and is also an actual attribute of a park (i.e., adjacency to another park.)
To me, this Apple Maps example in Richmond is really problematic, in that you have 2 adjacent cemeteries adjacent to a park and you cannot tell what is what a reasonable zoom for visual distinction of a large area.
Got it, like understanding the growth (or winnowing) of specific parks? That makes sense. Hmm I think, let's test some border designs first to see if we find what we like as it still can work before considering changing tagging/data
To me, this Apple Maps example in Richmond is really problematic, in that you have 2 adjacent cemeteries adjacent to a park and you cannot tell what is what a reasonable zoom for visual distinction of a large area.
That sounds like a very good case for giving cemeteries a different treatment than parks. 😉 Apple has basically decided that they want all greenspace to look the same and have the user rely on the clickable POI icons to find out more.
Style change requested
Right now, there is no border treatment for parks, so it's hard to tell where one park area ends and another begins.
This is of interest in Richmond, VA, because Maymont Park was historically a private estate adjacent to Byrd Park, and after the Maymont estate was willed to the city, it became a public nature reserve that is experientially quite different from Byrd park, but on the map, it all just bleeds together.
In addition, there are sections within the park (e.g. Carillon Tower Grounds) that should be visually distinct from the rest of the park.
See here: https://www.openhistoricalmap.org/#map=16/37.5418/-77.4724&layers=O&date=2023-12-30&daterange=1700-01-01,2023-12-31
I couldn't find any good comps of any other online maps that do this well, either, and most make cemeteries look a lot like parks, so if a cemetery is next to a park, all bets are off as to where one stops and the other starts, even though there'd be clear distinctions on the ground or on hand-drawn maps.
Affected Tag or Tags
adjacent areas ways and relations tagged with
leisure=park
e.g.: Maymont: https://www.openhistoricalmap.org/way/199482918#map=17/37.53511/-77.47796&layers=O&date=2023-12-30&daterange=1700-01-01,2023-12-31 & Byrd Park: https://www.openhistoricalmap.org/relation/2744271#map=16/37.5416/-77.4791&layers=O&date=2023-12-30&daterange=1700-01-01,2023-12-31