zelonewolf / openstreetmap-americana Goto Github PK

When zoomed in beyond the level where a boundary shows a centrally-placed label, a label should be drawn along the edges. In the case of adjacent areas, labels should be drawn on either side.

Here is an example from openstreetmap-carto:

Boundary labels should be drawn for administrative boundaries and protected areas.

When device pixel ratio (DPR) is > 1, standard width shields are used for 1 and 2 digit route numbers and the wide shield is used for 3 digit route numbers. Here is DPR 2 for example:

The same area at DPR 1 shows wide shields used for 1 and 2 digit route numbers which should be using the regular width shield:

True-to-life highway shields are not optimized for map display. We should consider using simplified shields, specifically:
http://github.com/1ec5/rebusurance

Integrating these shields early in the project timeline has the following advantages:

1. Demonstrates the technological process for integrating an external SVG icon set
2. Demonstrates a mechanism for icon scaling
3. Provides an initial set of attractive shield icons that will motivate contributors to participate in style development

The following integration process is proposed:

1. A script downloads a rebusurance release package
2. SVG icons are extracted and copied into the icons folder with a standardized naming convention and prefix (so they can be filtered by .gitignore)

This will allow the shields to be automatically integrated into the style sprite sheet without replicating them in the repository.

There are two possible strategies for scaling that need to be investigated:

1. Use rsvg-converter to pre-generate 2- and 3-digit versions of shields
2. Create just one version of each shield and scale them in the client style. This option would need to ensure that there's sufficient resolution in the rastered shield to support scaling.

Marine sanctuaries (protected areas over water) should be styled differently from ashore protected areas.

This is discussed in @zekefarwell's comment in #49 (comment).

There is currently a stand-off between water color and protected area boundary line color that results in water coloring that is probably a little too dark, but provides a nice contrast with the boundary lines. Ideally, we would make the marine lines a different color, perhaps a dark blue:

Depends on #20

Functionality description:

A user should be able to open a tray or menu that allows them to set a language and 1 to N fallback languages. Upon change of this setting, the map should change to use the selected languages.

For debugging I might like let map = window.map = new …. The downside of modules is you don't implicitly get global variables, naturally.

(Technically this can be accomplished by making it an export but you'd need to write the correct import at the console.)

Originally posted by @jleedev in #57 (comment)

Motivation: Should be obvious, but of note — the river areas as simplified by openmaptiles have large gaps at low zoom levels and the linear rivers are needed to make this look right.

Desired qualities for the waterways (brainstorm harvested from slack):

• Serif font? We sure have a lot of sans fonts to choose from but no serifs. This is really a question for this style as a whole, but distinguishing "natural" features with a font choice seems to be a thing.
• Waterway labels appear at z12, which I'd consider fairly late. This might be a good boundary for rivers in general at the expense of not labeling large rivers.
• Some way to distinguish large and small rivers.
  • Depend on explicit width tagging? This exists almost nowhere.
  • Detect the river area with a spatial join? One can dream.
  • Join with wikidata to get the watershed area or discharge? Could work.
  • Absent any of these, the label needs to look good on a small river with no accompanying water area.
• A width heuristic — this is pretty much for small rivers. It can provide a nice transition for when the water area stops being mapped. If we assume that a typical river is 20 feet in width before we can expect the water area to have been mapped, then we can calculate that at z22 (at the equator) this should be 160 pixels in width, then ramp down by powers of two accordingly down to some minimum of (say) 2 or 4 pixels, then switch to a different ramp down to the minimum zoom.
  • Would it be possible for the style to multiply physically based widths by the cosine of the latitude?
• Curviness with regards to label placement. The default text-max-angle of 45° causes very few labels to appear on smaller streams and rivers except at very high zoom levels. This is actually somewhat convenient, the straightness of a river is a proxy for its size, so we get labels on only the biggest rivers for free.
  • Find a reasonable text-max-angle that results in more labels without being an unreadable mess.
  • Another approach: Add a separate layer with aggressively simplified waterways for the purpose of labeling?
• Generally speaking, make sure the labels look good embedded in a water area and against arbitrary non-water stuff.
• Could have stream labels offset running next to the waterway, and river labels running along the waterway, perhaps.
• Render waterway labels under bridges? Is this crazy pants or would it improve legibility.

At low zoom levels, the highway network should only show Interstate highways, and not other highway=motorway.
At even lower zoom levels, the highway network should only show Interstate highways that end in a 0 or 5.
At the lowest zoom levels, shield rendering should be suppressed and the route network shown only.

Blocked by #9.

For roads which share multiple routes, it is desirable to show grouped shields at higher zooms. This is consistent with highway shield groupings on American road signs.

Real-world examples of group signs:

Depends on #5

In some cases, SVG resizing has not worked completely, resulting in partially-resized images, such as:

Image resizing is done using a sed command to set the transform attribute, however, this seems to be not working the same way on all platforms. Instead, this should be converted to an xmlstarlet command to more reliably edit the XML.

Thanks for your great work creating this style. I was wondering if it would be possible to create a style.json from the style? As I understand there are currently multiple .js files that can be used in combination with Maplibre-GL to render a style.

I would like to use the style in combination with for example https://github.com/maptiler/tileserver-gl

This is (as far as I am aware) only possible with a style.json.

So I was thinking, since all the rules are available as js files, wouldn't it be possible to generate a style.json from this?

Depends on #19

A key feature of vector tiles is the ability to switch languages for name labels. OpenMapTiles provides name:xx tags wherever a name tag is available. Proposed is that the following parameters can be parsed from the querystring:

*lang0=xx - use name:xx tag for name features
*langN=xx - use name:xx as a fallback language if the lang0 language is not available. N is numbered from 1 and counting up

If none of the specified languages or fallback languages are set, this will default to one of the standard name values (one of name, name_int, or name_latin).

In javascript, a JSON fragment will need to be generated which creates a case statement to switch the specified language names, which is then inserted into the appropriate locations in the style JSON variables.

A holistic design is desired for the project which would provide contributors with guidance in implementing features, which includes but is not limited to:

• Which features to emphasize, which features to de-emphasize, and which features to exclude entirely.
• Stylistic purpose at each zoom level (or cluster of zoom levels)
• Color assignments

It is desired that a holistic design be inspired by American aesthetics.

#35 added administrative boundaries for 2, 3, 4, 6, and 8, as these are the most commonly used ones. However, level 5 and 7 are in use also, for examples:

• level 5 is used for New York City
• level 7 is used for Illinois townships

Level 5 is also used for Ireland provinces, but this tagging is questionable. However, it may be a convenient test area to inspect render support.

In Georgia, the following relation contains many roads across the state which are not "GA 100 Spur":

https://www.openstreetmap.org/relation/1308854

This is causing an unreadable "GA 100 Spur" Georgia shield to be drawn in various wrong places across the state.

Each of the segments in this relation needs to be assessed to determine what route relation it's really supposed to be a part of.

#62 provided an initial implementation of the road system through tertiary, and #82 provided an initial implementation of expressway rendering. The high-zoom road network needs to be holistically considered to ensure that it's appropriately conveying relative prominence at these zoom levels.

Additional refinement is needed to ensure that:

1. More prominent roads are rendered more prominently. Currently, the progressive switch from stroked to cased roads has the side effect of making the cased roads look less important that the thick stroked roads. For example:

2. Expressways are visually understood to be more prominent than non-expressway versions of the same highway class.

3. Expressway styling is not confused with tunnel rendering. For example:

A simple place layer is needed in order to demonstrate name language-switching technology in vector tiles. This requires implementing the OpenMapTiles place layer with a point icons and labels.

Suggested icons:

• For capital=2, a 5-pointed star encased in a circle.
• For capital=4, a filled circle surrounded by concentric circle.

The road vector information should allow for the data necessary to allow someone to click a feature and be provided additional context.

At the very least, each US highway should have information that can take you to the corresponding wikipedia page.

ex: https://www.openstreetmap.org/way/21775289 US:US=6 -> https://en.wikipedia.org/wiki/U.S._Route_6

This Mapbox GLJS tutorial is a good starting point https://docs.mapbox.com/mapbox-gl-js/example/filter-features-within-map-view/

See thread https://osmus.slack.com/archives/C01V02K52UX/p1641410558052000
Related to #75

Currently, motorway links gap in the zoom 10-12 range. Instead, we should render them thin a little lower in zoom and then transition to rendering them thick so it all blends in at junctions.

Example below:

Location: https://zelonewolf.github.io/openstreetmap-americana/#11.82/50.91347/7.05276

Keep things clean early on with checks that run on each PR.

Github Actions is a simple solution and keeps the management within this repo, it's free for public repos. TravisCI is another option.

There's a prebuilt Action that has some connivence methods, including updating PRs/commits for you - https://github.com/marketplace/actions/prettier-action

This image from lower Manhattan shows that stacked tunnels are a problem, in addition to stacked bridges:

The goals of the codebase organization are:

1. It's easy for contributors to figure out where to edit elements of the style
2. Files and variables are named in a consistent and predictable way
3. Copy/paste is minimized by using defined constants for repeated colors, styles, filters, etc.

The initial code structure will implement just one object feature: motorway, including tunnels and bridges.

Map legends may not be the most popular on web maps, but they offer the opportunity to showcase the rich information held within the vector data being shown.

A floating/sidebar legend could display the currently visible highway shields (via querying the visible roads and determining the shields from there).

Here is an example for querying the rendered features with MapboxGlJS https://docs.mapbox.com/mapbox-gl-js/example/filter-features-within-map-view/

See thread https://osmus.slack.com/archives/C01V02K52UX/p1641410558052000
Related to #76

In Hungary, there are two separate shields for motorway and primary routes, however they use the same network value. Motorway shields use a ref with an "M" prefix. Since these shields are the exact same style, just with different colors, we can use the same type of code that we use for the special Georgia routes (may require re-coloring the SVG to be black as a base).

Note: tunnels on motorways should render the same as non-tunnel on low zoom <7

Originally posted by @Mashin6 in #4 (comment)

Many protected area boundaries cross water and land, so the styling absolutely has to contrast well with both. Using a different style for marine sanctuaries is not a solution to that problem. However, since marine sanctuaries are entirely over water a different style could look much better especially at low zoom levels.

On the coast of Massachusetts for example, there are two large protected areas. The boundary of Cape Cod National Seashore crosses land and water, but stays close to the coast. At low zoom this is barely visible and the boundary line just looks like it's on the shore. On the other hand, the boundary of Stellwagen Bank National Marine Sanctuary is entirely in the ocean. The coast of California also has many of these marine protected areas sticking far out into the ocean.

Using a blue outline where the boundary is entirely or mostly over water would be a nice cartographic effect and less distracting than a green outline in the middle of the ocean. We could also decide to simply exclude marine sanctuaries on the basis that this map style focuses on land based features.

Originally posted by @zekefarwell in #49 (comment)

Labelled or icon-indicated highway exits are a common feature on American-style maps, either as a label or often with a white square or diamond to indicate an exit. Highway exits are tagged with highway=motorway_junction in OSM. However, these objects are not currently available in openmaptiles.

Experiments with using iconified highway=motorway_link as a proxy for highway exits have shown that the icon placement is too erratic.

This is related to openmaptiles/openmaptiles#1114 which proposes to add this tag to OpenMapTiles.

If support is not added in OpenMapTiles, a custom vector layer is needed.

Slovenia’s A1 motorway relation is tagged network=SI:AC, so it should show up as . Instead, it shows up as a generic white rectangle:

@Mashin6 added a shield for the SI:AC network in 4a9c7a0, but it fell out of the branch for #72 at some point. The image is still present, but it’s unused. I wonder if this also accounts for the errors I see when zoomed out on Europe:

Uncaught RangeError: mismatched image size
    sa https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31
    la https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31
    clone https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31
    getGlyphs https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:35
    asyncAll https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31
    getGlyphs https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:35
    asyncAll https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31
    asyncAll https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31
    getGlyphs https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:35
    getGlyphs https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:35
    processTask https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31
    receive https://zelonewolf.github.io/openstreetmap-americana/js/maplibre-gl-custom-shields.js:31

Maybe someone force-pushed a commit, clobbering someone else’s, or maybe a merge conflict was resolved badly. I don’t think it’s possible to tell exactly what happened because of all the squash-merging that took place. We’ll probably want to go through the other commits to catch anything else that needs to be reapplied.

/ref #69

Historic US highway routes, such as those listed here:
https://commons.wikimedia.org/wiki/Category:Diagrams_of_California_historic_US_route_shields

...are not consistently mapped in the US, with the route network value network=US:US:Historic.

For example, Historic US 66 can be found and rendered along the TX/OK border like so:

Help is needed to catalog and map each of these historic US highway routes so they can rendered with the historic brown shield color.

Currently, hiking routes are rendered exactly like highways. How do we want to handle hiking routes?

https://en.wikipedia.org/wiki/E4_European_long_distance_path
https://en.wikipedia.org/wiki/National_Blue_Trail

https://www.openstreetmap.org/relation/7176710

Even though this project is currently focused on the lower zoom levels with large features like roads, I think it’s time to start thinking about what we’d need for proper rendering of points of interest at higher zoom levels, because the tagging system for some points of interest may fit American cartographic needs even less well than for transportation features.

For sure, the style would at some zoom levels mark schools, which are important community institutions that serve as a point of reference for other places around town. The description below is focused on what a reasonable end result might look like, but it’s likely that we’d need to focus on coverage of certain tagging schemes to make the suggested treatments work.

Icon

Conventionally, street- and community-level maps of the U.S. depict schools as pitch-roofed buildings with a pennant-shaped flag on top.

Typically, community institutions (such as schools, post offices, hospitals, and police and fire departments) are marked by only a simple icon at middle zoom levels where there wouldn’t be enough room for a full label. However, some maps pack a bit more information in school icons:

• Some place a small letter inside the building to indicate the school’s classification – typically “E” for elementary, “M” for middle school, and “H” for high school, but other initials are possible.
• Some highlight middle and high schools with a darker fill than elementary schools to emphasize the relative size and importance.
• Some place more than one flag on the roof to flag an institution of higher education.
• Some replace the pennant with a religious symbol such as a cross for religious schools. (The color or letter distinguishes the religious school icon from the church icon.)

(Some maps in my collection use the flag-on-house symbol for a fairgrounds, and some use a filled square for educational institutions, but those seem to be in the minority.)

Label

I recall seeing some maps that use the label instead of the icon to indicate a school’s classification. For example, it might say “(Grades 1–8)” in fine print beneath the school name.

Fill

Many maps fill school buildings in a darker or more brilliant color than other buildings, to give them more prominence.

Some maps also fill schoolgrounds, particularly the ones that are at a high enough scale that they don’t need to show an icon.

Somewhere on index.html, we need to add a visible:

© OpenMapTiles © OpenStreetMap contributors

Branch motorways in Italy are numbered based on the two motorways that they connect:

The shields on these roads use a stacked configuration as follows:

In the database, these route relations use the form ref=A7/A26. These will need to be parsed and split by the slash in a vertical configuration.

The current problem of osm-carto is that it is a map for everything and nothing at the same time. It is supposed to serve mappers to check their mapping progress, but is also supposed to be for general public. It is just filled with too many different objects that make it too dense.

One way to go around is to have several separate tiles styles: 1. for public. 2. for mappers. 3. public transport ,...
-OR-
I was thinking that since the actual tile rendering is happening on the user side to have some sort of switches that would turn on/off displaying of some objects. So there will be one style for the tiles but the user would choose which parts of that styles would be displayed. For example there is no need to have the default of displaying of manhole covers and utility poles, but with a switch one can display them if needed.

Issues:
I don't know if this is technologically possible
Probably depends on solving of #9

The recent changes in #26 to fix stacked bridges causes bridges to not render at zoom 8 and lower:

This is because OpenMapTiles suppresses the layer tag at lower zoom, so the style needs to ignore layer information at low zooms.

West Virginia has unusual 2-part "fractional" route designations as indicated here:
https://www.flickr.com/photos/andrew-turnbull/5904974507

How should these be rendered in the style?

Blocked by #6

The following sprite load code:

https://github.com/ZeLonewolf/openstreetmap-americana/blob/7d38d24ad371e1c638d4d9ee5d9120b83a81a706/style/index.html#L84

Creates a root-referenced URL for sprites. While this will work locally, it will break on gh-pages. This needs to be converted into a javascript-generated absolute URL referenced to the current host name and path.

As noted in mapbox/mapbox-gl-js#9225 (and presumably proliferated into mapLibre, relative URLs are not supported.

This probably affects other admin_level=4 areas as well, but these are two most ridiculous looking examples I've noticed so far. Rather than having their labels in a spot that could reasonably be described as the center of the state, they are way down on the southern border for some reason.

This only happens when using tiles from MapTiler cloud. The labels are placed sensibly when using custom generatated OpenMapTiles:

This same issue can be see on other MapTiler map styles as well.
MapTiler Bright:

MapTiler Topo

This ticket is a central point to capture discussion on how road lines at various levels should be styled. Common elements of road styles in American road maps included:

1. Separate colors for toll vs free motorways
2. A sequence of decreasing styles for roads of decreasing importance. For example: Cased Red->Red->Black->Gray is a common theme in AAA road maps.
3. Road styles based on importance rather than by network. We may want to use a scheme that is a hybrid approach between highway classification and road network.
4. Road labels on the sides of road lines, rather than squeezed inside the casing.
5. Cased white inners for divided carriageways.

A baseline structure at a medium zoom might look something like this:

• highway=motorway -> Cased red
• highway=trunk + US highways -> thick red
• highway=primary + state highways -> red
• highway=secondary + county highways -> black
• highway=tertiary -> thin black
• highway=unclassified, highway=residential -> thin gray

Not entirely sure what to put here you told me to remind you about the idea of rendering boundary=census. While I understand in some locations CDP's have overlap or border gore with existing towns/cities, in many counties they are their own entities which are ignored by standard carto due to being a American issue. Was hoping a America style would allow for the rendering of what is a uniquely American type of settlement. If needed, I can also help with establishing boundaries and finding bad data.

It is common for US-style maps to have special icons for capitals (national, state) and perhaps even county seats for states that have them.

Suggested icons from #19:

• For capital=2, a 5-pointed star encased in a circle.
• For capital=4, a filled circle surrounded by concentric circle.

It would be useful to review examples of special capital icons on US-style maps for inspiration.

Consider: https://www.npmjs.com/package/dotenv

So that you can put the localhost URL in your working directory .env file (and .gitignore it), and the deployment process can use the production URL.

Originally posted by @jleedev in #62 (comment)

Highway maps commonly show expressways–also known as limited-access, controlled-access, or divided highways–with a distinct line style from standard two lane highways. Beyond simply using a different color, expressway lines are usually thicker and have higher contrast casing. Some examples:

Other than highway=motorway OSM highway classifications are functional, not physical, so there are both trunk and primary expressways (I don't think secondary expressways exist but I suppose it's possible). So to indicate the physical characteristics of an expressway we have a separate tag, expressway=yes. It would be great for this style to be the first to render expressways distinctly based on this tag. Below are some rendering ideas for how this could look.

Low zoom where individually mapped carriageways merge together as one line

Higher zoom where individually mapped carriageways are visible

All motorways are expressways, so highway=motorway implies expressway=yes and would always be rendered with the expressway line style. trunkandprimarywould have a standard highway line style and an expressway line style that would be used whenexpressway=yes` is set.

Currently the expressway tag is primarily used in North America, but the concept is applicable elsewhere as well. In other parts of the world the motorroad tag is far more common. While expressway defines the physical construction of a highway, motorroad defines legal access restrictions (i.e. a road where only for motor vehicles are allowed). Although the definitions are different, in practice motorroad=yes is often applied to the same or very similar kinds of limited access, divided highways as expressway=yes. So for this map style we may want to interpret motorroad=yes as implying expressway=yes when the tag is absent and render these highways with the expressway line style. In the case of an explicit expressway=no the standard highway line style would be used.

Update 2021-11-04:
My thinking on the above has changed and I'm not sure if it is actually a good idea to assume that motorroad=yes implies expressway=yes when expressway=no is not present. I more clearly understand now that the reason for the motorroad=yes tag is that in countries where it is used, access restrictions are not explicitly signed on these roads. Instead there is a blue sign with an icon of a car which means "motor vehicles only". Since the sign doesn't say exactly what modes of transport are prohibited it's hard for mappers to set all the right access tags (horse=no, bicycle=no, etc). In North America on the other hand, access restrictions generally are explicitly signed (No pedestrians, No bicycles, etc) so it is easy for mappers to tag them explicitly and there is no need for the motorroad tag. All this is to say that while motorroad=yes is tagged on many roads that physically qualify as expressways, it also is tagged on some that do not so I'm not sure we should use it for this rendering distinction.

Referring to this conversation:
https://osmus.slack.com/archives/C01V02K52UX/p1640606101380400

When a commit is made to the main branch, it should trigger an update of the gh-pages branch (where the public map is hosted).

An example of how to do this is here, courtesy of @wipfli:
https://github.com/maplibre/maplibre-gl-js-docs/blob/main/.github/workflows/build-test-deploy.yml

#49 added rendering for protected areas. However, this starts at zoom 6. In the western United States these areas are very large and it would be appropriate to render these in generalized form as low as zoom 4 or 5.

This change requires an update to OpenMapTiles to make generalized protected area polygons available at a lower zoom.

Here is a current zoom 6 rendering of protected areas in the western United States:

We currently rely on the MapTiler Cloud service to serve vector tiles, however, this setup does not allow us to customize what data is served in each tile. Ideally, we will need to self-host a vector tile server that can be customized to the specific needs of the style.

This issue blocks #1

@zekefarwell reported that some highway on- and off-ramps are being marked with Vermont Route shields even though they aren’t part of any Vermont Route but merely lead to or from them. Even once ramps are rendered at the zoom level shown below, it will be difficult for a user to visually distinguish between a ramp that actually carries VT 289 and one that merely connects to it.

These highway=motorway_link ways have been added to the connecting route relations with the role link, which is quite rare in the U.S. There are 1,049 link member ways of route relations in the U.S. Of those, 526 are members of route=road relations. Usage of link is largely limited to Vermont, the Capital Region of New York, and a few routes in New Jersey and Oregon. Most were added by three mappers. To my knowledge, there has never been any discussion or documentation about link roles in the U.S., but there is a brief mention on the wiki page about route relations.

More complex interchanges would become quite a mess. It’s very likely that some urban interchanges would exceed the six-route maximum concurrency size, since there’s no distinction between the routes that a ramp leads toward versus those that it departs from.

https://osmus.slack.com/archives/C2VJAJCS0/p1631849218278500
https://osmus.slack.com/archives/C01TUSZ1Q7J/p1641614118015900

For better map readability, more important cities should have larger labels. An analysis of why this is important can be found here:
https://www.justinobeirne.com/google-maps-label-readability

OpenMapTiles has a rank column in the place layer that can be used for the functionality:
https://openmaptiles.org/schema/#place

This can be implemented in a manner similar to how we set the capital and city labels:
https://github.com/ZeLonewolf/openstreetmap-americana/blob/main/style/layer/place.js#L19-L27

The Americana style should be deployable to anyone that wants to self-host. This includes the following tasks:

• A style JSON (we'll call it americana.json) is generated at compile time and posted to gh-pages where it is used in favor of the currently dynamically generated object. (#68 --> #736)
• Shield definitions are available as a JSON file which users can edit (#735)
• A separate library is available for runtime shield generation, which consumes the shield definitions and sprites.
• Documentation is added that's sufficient for a style user to host their own copy, including shields. The Americana runtime would include compiled sprites, the style JSON, and a javascript library for dynamic shield generation.