Public statement of Cartographic Design Principles

[ZeLonewolf]

Based on discussion in #383, we should be more specific about our design principles for this style. I'd propose that we add a Cartography section to the README.md describing our design principles.

I'll kick this off with some ideas:

• The cartography is inspired by the designs seen in North American paper maps, including atlases, road maps, topographic/hiking maps, city/tourism maps, public transit maps. Paper maps cover a single fixed zoom; artfully blending single-zoom paper map design principles into a zoomable digital map is a key cartographic challenge.
• Like with paper maps, we aim to render features in a way that prioritizes the conveyance of information to the map reader. We aim to keep information density within human-digestible ranges, recognizing that this may be a challenge of balance between urban and rural areas.
• We will render a global map according to these principles, while supporting features outside of North America on a "best effort" basis.
• A a community style, we prioritize good mapper feedback over perfection and completionism. We will not fix a mapping or tagging problem with a rendering workaround.

Any others or thoughts/edits?

[1ec5]

A statement of design principles will serve this project well. It’ll guide contributions upfront, so that we don’t have to be the bearer of bad news after someone has put too much effort into an ill-fated design. It’ll also help the OSM community know what to expect in the future, even as our technical roadmap remains fluid.

The cartography is inspired by the designs seen in North American paper maps

“North American” is probably shorthand for the U.S. and maybe Canada. I’d very much love for Americana to serve all of America, but the reality is that there probably are historical differences in cartographic practices in Latin America. This would be an interesting area to research and a good reason to reach out to other OSM communities in the region.

A a community style, we prioritize good mapper feedback over perfection and completionism. We will not fix a mapping or tagging problem with a rendering workaround.

In the short lifetime of this project, we’ve seen cases where the map’s cartographic needs have driven tagging changes, as well as cases where the tagging has had to catch up to the rendering. Perfectionism aside, we do seem to value inspiring mappers with what’s possible rather than just reflecting what they’ve done. That’s a balance we’ll learn more about over time.

My concrete suggestion for this point is that we prioritize mapper feedback within the design constraints of the kind of map we’re producing. This isn’t quite a raw data visualization for debugging purposes. If tomorrow we decide that rendering manhole covers is important for supporting a new water infrastructure mapping initiative, then we’ll need to sketch out enough related functionality that the manhole covers won’t seem like a random addition bolted onto the side.