Inspect Works, But I Cannot Get OpenMapTiles to Work

maplibre / maplibre-gl-inspect

Maplibre GL Inspect adds an inspect control to maplibre-gl-js to view all features of the vector sources and allows hovering over features to see their properties.

https://maplibre.org/maplibre-gl-inspect/

BSD 3-Clause "New" or "Revised" License

39 stars 7 forks source link

Inspect Works, But I Cannot Get OpenMapTiles to Work #49

Closed jlpoolen closed 3 months ago

jlpoolen commented 3 months ago

I'm not sure if filing within this project is the best choice. But since your project's code is working, I thought I'd start here.

I built and installed the openmaptiles project using the quickstart.sh specifying "North America USA Oregon". When I started the Node server (which was built inside a docker container) I visited the home URL at port 8080 and got this: firefox_2024-06-13_17-15-35

Then I can click the Inspect button and drill down, i.e. http://192.168.1.240:8080/data/openmaptiles/#13.4/44.91979/-123.00226, and all vector data appears. Hurrah! firefox_2024-06-13_17-16-41

Having vector data rendered in a map is precisely what I have been seeking. (I want to work in QGis and enhance the base layer for the Qgis2threejs plugin.) I noticed the default code for openmaptiles turned off the toggle switch for Inspect, so I deployed a similar page with the toggle switch displayed and when I toggled off Inspect, the underlying map is blank. So my next task has been to create a simple HTML page containing a map which displays the various layers for Oregon which I have successfully installed into an mbtiles [SQLite] database (I also have PostGIS, but have not dug into that until I get what should be this simple task accomplished). I also have an openmaptile.json file containing all the styling information -- but you probably can deduce that by the fact that I have a correctly rendered map as depicted above.

I have been trying all sort of things to try and get a simple HTML page to render just like your Inspect does, but without the mouse-pop-up feature (gone to the extent build and and debug lines in rust for the Martin server) and I do seem to be able to have the openmaptiles Node server in conjunction with my Apache server serve up a page like what Inspect renders.

Here's an example where I access the shared "data" mount (the openmaptiles project directory "data" is mounted in the docker environment) which is without an HTML page, I'm guessing its the magic of Node templating, but does have the Inspect feature activated: tvnviewer_2024-06-13_17-49-33

So, I'm not sure what to do to efficiently utilize whatever help might come my way. I have some pared-down demo HTMLs, one with the Inspect included and displays the vector tiles when Inspect is toggled and goes blank when toggled off, and just a plain old simple map such as exemplified on the mapLibre site.

I am determined to be able to serve up my own tiles and not rely upon a commercial service or service which requires and authentication key, and that goal may be what is tripping me up?

What can I provide to help flush out why the openmaptile server (which utilizes the maplibre technology, including this Inspect project) works in an "Inspect" mode, but not otherwise. Again, maybe Inspect somehow marshals all the layers automatically whereas in a basic instance, I have to manually add layers and have not done so?

I have spent at least five days trying to get over this hurdle and am mystified that I'm like a fish out of water. I do have a pretty good technical knowledge having built my on Gentoo Xen servers for over a decade and done various things like cross-compiling in a distributed compiler environment and utilized PostGIS in several practical applications.

Thank you for your time.

HarelM commented 3 months ago

It is not clear from the long message above what your problem actually is... Also, I would recommend using maputnik to style and inspect your data. If the inspect isn't working in maputnik it might mean your tilejson is misconfigured.

jlpoolen commented 3 months ago

It is not clear from the long message above what your problem actually is... Also, I would recommend using maputnik to style and inspect your data. If the inspect isn't working in maputnik it might mean your tilejson is misconfigured.

1) Clarifying my problem

Visit the Getting Started at MapLibre-gl-js and construct an HTML file based on their code snippets. Here is my HTML, demo1.html, incorporating their code snippets which I have staged on my Apache server:

<!DOCTYPE html>
<html>
    <head>
        <meta charset='utf-8'/>
        <title>Maplibre GL Inspect</title>
        <meta name='viewport'
              content='initial-scale=1,maximum-scale=1,user-scalable=no'/>
       <link rel="stylesheet" type="text/css" href="http://192.168.1.240:8080/maplibre-gl.css"> 
       <script src="http://192.168.1.240:8080/maplibre-gl.js"></script>
        <style>
        body { margin:0; padding:0; }
        #map { position:absolute; top:0; bottom:0; width:100%; }
    </style>
    </head>
    <body>
        <div id='map'
             style='width: 400px; height: 300px;'/>
        <script>
var map = new maplibregl.Map({
  container: 'map',
  style: 'https://demotiles.maplibre.org/style.json', // stylesheet location
    center: [-123, 44.9], // starting position [lng, lat] - Salem, Oregon
  zoom: 3 // starting zoom changed to 3 from 9
});
</script>
    </body>
</html>

(I modified 1) the URLs for the CSS and JavaScript to my local OpenMapTiles server since my requests to the unpkg.com/ were failing, 2) the default coordinates, and 3) the default zoom.)

Here is a screenshot of demo1.html (which points to demotiles.maplibre.org/style.json):

tvnviewer_2024-06-14_08-58-18

The map only has continents. So I decide rather than procure a key from Map Tile Server, I build my own server using the OpenMapTiles project.

The successful build of OpenMapTiles displays on my server a page shown in the screenshot "Tile Server GL" of my initial comment on this Issue. When I click the blue "Inspect" button, there is displayed a map with all the features formatted -- also shown in my initial comment. The map displayed within the Inspect is the kind of map I would like to create, except I do not want the feature of the mouse inspecting. The rendering of the map from my tile server demonstrates that the features of Oregon have been stylized, so I should not have build styles from scratch, but, in instead just use the styles utilized by the Inspect code.

I want to be able to construct a map that renders like that in the Inspect window against my State of Oregon Tile server and I want to harness the styles the Inspect code uses.

If I modify demo_1.html and save it as demo_2.html with this change pointing to the JSON created in the build of my OpenMapTiles project:

 ` style: 'http://localhost:8080/openmaptile.json', // Oregon stylesheet location w/207 layers `

I get a blank screen and there are errors in my Firefox Java console. There errors may be viewed at: https://pastebin.com/dBW4wMdw (1year life.)

Contrast the Java Console messages with those generated when I access the OpenMapTile server default page and then the Inspect page where I zoom into features within Salem, OR. https://pastebin.com/nu3TLVsU (1 year life.)

The quandry I face is that the "Inspect" demo shipped within the OpenMapTiles project can render my vector tiles, but the simple HTML I constructed and pointing to valid JSON cannot. Why can't I create an HTML page that display the same rendering as the "Inspect" page?

2) Maputnik

I have tried Maputnik, both the version included in the OpenMapTile project, and installing separately, and I'm having problems, especially around caching either by Firefox or Maputnik (I used Control+Shit+R in Firefox, but to no avail). Moreover, the version display on both Maputnik sessions are 1.7 which I understand is 4 years old. I was hoping the separate installation using the docker command would bring in the current 2.0 version. When I did have some moments of rendering, there were some complaints by Maputnik about "matches", but I got to a point where I could not get anything to appear, even with restarting Firefox and restarting the Maputnik server. While there may be problems with my JSON, then I am really curious why the default page's Inspect sub-page does not demonstrate that problem.

HarelM commented 3 months ago

Thanks for the extra info. It looks like the style you are using is not valid, and I would advise to use chrome instead of firefox to avoid some irrelevant console warnings. Overall, I would advise to increment complexity and keep things working as your are trying to solve multiple issues as the same time and the noise is too high. Overall, this library is working as expected as far as I know, and maplibre does as well (I maintain both of them).

HarelM commented 3 months ago

Regarding maputnik, you can use the online version of it, which is 2.0. note that the style is saved in local storage, so refreshing the page won't clear the style...

jlpoolen commented 3 months ago

Thanks for the extra info. It looks like the style you are using is not valid, and I would advise to use chrome instead of firefox to avoid some irrelevant console warnings. Overall, I would advise to increment complexity and keep things working as your are trying to solve multiple issues as the same time and the noise is too high. Overall, this library is working as expected as far as I know, and maplibre does as well (I maintain both of them).

Thank you. Is there a way to duplicate the rendering as displayed from the default page? I've tried including the "Inspect" CSS and JavaScript, but to no avail.

HarelM commented 3 months ago

You can try and see what is written in openmaptiles code or inspect the network to see what is being sent to the browser, but I wouldn't recommend it in general...

acalcutt commented 3 months ago

Here is an example using my own own tileserver-gl with openmaptiles style. it seems to work as expected https://stackblitz.com/edit/web-platform-janbub?file=index.html

For your issue, it sounds like your blank page might be caused by a style error. maybe try a different style and see if it makes a difference. If your page is blank right away you probably need to fix the style error so the page can load.

Other than that error, your style.json needs to use a source for OpenMapTiles that includes the "vector_layers" information, like https://tiles.wifidb.net/data/openmaptiles.json . If you don't have vector_layers your initial map would load, but when you click inspect it would be blank since it doesn't know anything about the layers

jlpoolen commented 3 months ago

Here is an example using my own own tileserver-gl with openmaptiles style. it seems to work as expected https://stackblitz.com/edit/web-platform-janbub?file=index.html

For your issue, it sounds like your blank page might be caused by a style error. maybe try a different style and see if it makes a difference. If your page is blank right away you probably need to fix the style error so the page can load.

Other than that error, your style.json needs to use a source for OpenMapTiles that includes the "vector_layers" information, like https://tiles.wifidb.net/data/openmaptiles.json . If you don't have vector_layers your initial map would load, but when you click inspect it would be blank since it doesn't know anything about the layers

Thank you very much, Andrew. I've forked your code... which, incidentally appears to mirror precisely what I have tried (and various permutations) and will take very careful look. I just know I'm missing one itsy-bitsy setting given that the my tiles do appear in the OpenMapTile default "Inspect" page. Fragile is an understatement. I really appreciate your reaching out and when I succeed, I'll advise further.

acalcutt commented 3 months ago

btw, your layer errors at https://pastebin.com/dBW4wMdw reminds me of https://github.com/maplibre/maplibre-gl-js/issues/4212 , thought not quite the same it might be a similar syntax error in the filters of those layers

jlpoolen commented 3 months ago

btw, your layer errors at https://pastebin.com/dBW4wMdw reminds me of maplibre/maplibre-gl-js#4212 , thought not quite the same it might be a similar syntax error in the filters of those layers

Yes, I had either 13 or 27 of those with an illegal "matches" in the JSON the openmaptile "quickstart.sh" created and I tried a dragnet replace with "sed", but I felt like I was chasing an issue not germane to the fact that nothing would display.

I've compared your style sheet with mine and found what may be the problem point: yours has a URL, whereas mine has a local file that probably is only meaningful within the docker instance! Once outside of the docker container, a readily resolvable URL most certainly needs to be used: "url": "mbtiles:///data/tiles.mbtiles" which, perhaps, some script handles or replaces with a URL or if served from within the docker contain, can accept local file references. Just starting to test now.

acalcutt commented 3 months ago

Did you follow the instructions at https://github.com/openmaptiles/openmaptiles/tree/master/style to do the build-style steps? I think that is what I had done.

acalcutt commented 3 months ago

Once outside of the docker container, a readily resolvable URL most certainly needs to be used: "url": "mbtiles:///data/tiles.mbtiles" which, perhaps, some script handles or replaces with a URL or if served from within the docker contain, can accept local file references. Just starting to test now.

Yes, that is correct. In the case of tileserver-gl, any styles that you use the mbtiles:// prefix for will automatically generate a http:// url on your public tilejson urls. Maplibre-JS needs http(s) url sources, trying to use mbtiles:// directly wouldn't work. Maplibre-Native can use mbtiles://, provided it points to a local file.

For example, the style I provide tileserver-gl for openmaptiles looks like this and uses mbtiles:// in sources https://github.com/acalcutt/wifidb-tileserver-gl/blob/master/tileserver-gl/styles/OpenMapTiles/style.json , however tileserver-gl rewites the sources to use the http endpoint it creates from the local files used. https://tiles.wifidb.net/styles/OpenMapTiles/style.json

jlpoolen commented 3 months ago

Did you follow the instructions at https://github.com/openmaptiles/openmaptiles/tree/master/style to do the build-style steps? I think that is what I had done.

No, I do not recall seeing these instructions. Thank you for bringing the page to my attention. I did go through the Build process and then became impatient and resorted to the quickstart to see if what came out at the end worked. When the scaffold of the environment (two docker instances!) was completed, I discovered at the http://localhost:8080 the "Inspect" window and its ability to render, I thought to myself, I'm only an hour away from accomplishing the framework that I would need. (I was sure wrong on that point.) I had even logged an Issue (#1662) with the project which I closed as realized I had accidentally skipped a step that was essential when I went back to audit my steps and correlate them with a log staged at pastebin.

So, thank you, again! Really is a bummer about the cache of Maputnik preventing me from accessing any of the menu commands, but I should not need that at the moment. I just need to craft my two JSON files pointing to the correct URLs.

Edit: June 15,2024 11:24 AM PDT

Although I had not followed the build-style instructions @acalcutt, I did have staged in the openmaptile project's directory the additional/built file: [project dir]/build/style/style.json I do not remember specifically building that file or thinking about having to create a style sheet. I audited my steps. The quickinstall.log shows a docker command:

155 docker compose run --rm --user=0:0 openmaptiles-tools bash -c 'style-tools recompose openmaptiles.yaml build/style/style.json \
   156      style/style-header.json && \
   157      spreet /style/icons build/style/sprite && spreet --retina /style/icons build/style/sprite@2x'

which, in turn, invokes the project openmaptiles-tools ( openmaptiles-tools is isolated in a docker instance?) script bin/style-tools, a Python script which creates the json files and accounts for the presence of the file style.json under the dirctory: /build/style (which directory is mounted/shared with the docker instance "openmaptiles-tileserver-gl-1").

So, the quickstart.sh tool does make a style.json file; however, it looks like it is of limited use and appears to contain bugs re: "match" operators, so the manual stepping through the style build steps probably needs to be accomplished. With @acalcutt kind help, I was able to deploy his style.json file which does not generate errors modified by substituting the source URL created by my quickstart session (I also removed the URLs to @acalcutt 's server so as not to hammer them), i.e.:

    "sources": {
        "openmaptiles": {
            "type": "vector",
            "url": "http://debian1:8080/data/openmaptiles.json"
        }
    },

and I achieved getting my Oregon tile set to appear in Firefox (Chromium errored out) -- although the HTMl required the inclusion of the follow CSS and script:

     <link rel="stylesheet" type="text/css" href="http://debian1:8080/maplibre-gl-inspect.css">
     <script src="http://debian1:8080/maplibre-gl-inspect.js"></script>

acalcutt commented 3 months ago

If you haven't looked already, the openmaptiles build process is using TileServer-GL to display the generated tiles. There is a lot of good instructions for the config of TileServer-GL at https://maptiler-tileserver.readthedocs.io/ which go beyond the defaults.

For example, some info on how tileserver-gl treats mbtiles:// https://maptiler-tileserver.readthedocs.io/en/latest/config.html#referencing-local-files-from-style-json

jlpoolen commented 3 months ago

Once outside of the docker container, a readily resolvable URL most certainly needs to be used: "url": "mbtiles:///data/tiles.mbtiles" which, perhaps, some script handles or replaces with a URL or if served from within the docker contain, can accept local file references. Just starting to test now.

Yes, that is correct. In the case of tileserver-gl, any styles that you use the mbtiles:// prefix for will automatically generate a http:// url on your public tilejson urls. Maplibre-JS needs http(s) url sources, trying to use mbtiles:// directly wouldn't work. Maplibre-Native can use mbtiles://, provided it points to a local file.

For example, the style I provide tileserver-gl for openmaptiles looks like this and uses mbtiles:// in sources https://github.com/acalcutt/wifidb-tileserver-gl/blob/master/tileserver-gl/styles/OpenMapTiles/style.json , however tileserver-gl rewites the sources to use the http endpoint it creates from the local files used. https://tiles.wifidb.net/styles/OpenMapTiles/style.json

I have found my problem and it concerns the "Optional array." syntax a text-font may have. See https://maplibre.org/maplibre-style-spec/layers/#text-font.

I made the leap of faith that if a font could not be found, it would not be show stopper and the rendering engine might default to an installed font on the system --- like many other applications. But in map stylesheets, the inability to load a font will break the rendering leaving the user with a blank screen, or possibly the rendering of some tiles that do not need a font?

Your style sheets has: "https://tiles.wifidb.net/fonts/{fontstack}/{range}.pbf" More definitively your styelsheet does employ the Optional array feature (just as mine does):

jlpoole@debian1:~/MapLibre/local$ pcregrep -Mo --buffer-size=16000000 '"text-font"\:\s*\[[^\]]+,[^\]]+\]' alcutt/acalcutt_style_202406141610.json
"text-font":["Noto Sans Regular","Noto Sans Bold"]
"text-font":["Noto Sans Regular","Noto Sans Bold"]
"text-font":["Noto Sans Italic","Noto Sans Regular"]
"text-font":["Noto Sans Regular","Noto Sans Bold"]
"text-font":["Noto Sans Bold","Noto Sans Regular"]
"text-font":["Noto Sans Bold","Noto Sans Regular"]
"text-font":["Noto Sans Italic","Noto Sans Regular"]
"text-font":["Noto Sans Regular","Noto Sans Italic"]
"text-font":["Noto Sans Regular","Noto Sans Bold"]
jlpoole@debian1:~/MapLibre/local$

Are you using a Node server to receive the requests for the fonts? I'm guessing you are. I, however, have been using Apache. My Firefox console shows: An error occurred: Error: AJAXError: Not Found (404): http://debian1/MapLibre/local/fonts/Noto Sans Regular,Noto Sans Bold/0-255.pbf Apache's log confirms the concatenation: 127.0.0.1 - - [22/Jun/2024:16:41:12 -0700] "GET /MapLibre/local/fonts/Noto%20Sans%20Regular,Noto%20Sans%20Bold/0-255.pbf HTTP/1.1" 404 486 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0"

Yet, I do have the fonts properly staged (with their dreaded space characters). I'm using soft links under /var/www/html to reach the the Noto fonts installed by the openmaptiles project:

jlpoole@debian1:~/MapLibre/local$ ls -la fonts
lrwxrwxrwx 1 jlpoole jlpoole 38 Jun 18 17:25 fonts -> /usr/local/src/openmaptiles/data/fonts
jlpoole@debian1:~/MapLibre/local$ ls -la /usr/local/src/openmaptiles/data/fonts
total 44
drwxr-xr-x 5 root    root     4096 Jun  7 09:26  .
drwxr-xr-x 3 jlpoole jlpoole  4096 Jun 11 18:07  ..
drwxr-xr-x 2 root    root    12288 Dec 14  2017 'Noto Sans Bold'
drwxr-xr-x 2 root    root    12288 Dec 14  2017 'Noto Sans Italic'
drwxr-xr-x 2 root    root    12288 Dec 14  2017 'Noto Sans Regular'
jlpoole@debian1:~/MapLibre/local$

What I did to work around this problem was to create a RewriteRule which replaces the mutliple fonts with a single one and thus allows a font file to be returned (not necessarily the font file requested). As you can see, the regular expression is still a work-in-progress. But, this is not the answer, the problem lies is generating requests with concatenated values from the array rather than processing each item in the array:

    jlpoole@debian1:/etc/apache2$ cat -n apache2.conf
   ...
   170  <Directory /var/www/>
   171          Options Indexes FollowSymLinks
   172          AllowOverride None
   173          Require all granted
   174
   175          RewriteEngine On
   176          RewriteBase /MapLibre/local/fonts/
   177          # Handle the case where fonts are requested with comma-separated names
   178          #RewriteRule "^(.+),(.+)$" "/index.html" # works
   179          #RewriteRule "^(.+),(.+)/(.+)$" "/index.html" [L] # works 
   180          RewriteRule "^(.+),(.+)/(.+)$"  "/MapLibre/local/fonts/Noto Sans Regular/$3" [L]
   181          #RewriteRule "^(.+) (.+),(.+) (.+)/(.+\.pbf)$" "/MapLibre/local/fonts/$1 $2/$5" [L]
   182          #RewriteRule "^(.+?)%20(.+?),(.+?)%20(.+)/([0-9-]+\.pbf)$" "/MapLibre/local/fonts/$3 $4/$5" [L]
   183  </Directory>

The RewriteRule is a hack should not be resorted to. The problem, I believe, lies within the code making the requests, something I shall try to determine. [Edit: removed unrelated paragraph]

acalcutt commented 3 months ago

TIleserver-gl should serve the fonts for you, provided your paths are set properly in your config and the fonts actually exist. If the fonts don't exists, maplibre-native raster endpoints will just show a blank page, while maplibre-js vector endpoints should be able to pull the missing fonts from the browser.

For fonts, I got the noto sans fonts from https://github.com/openmaptiles/fonts/releases/tag/v2.0 . I have also used https://maplibre.org/font-maker/ to make fonts from ttf files. My fonts folder looks like this

I have my tileserver-gl behind HAProxy right now, but when I had it on apache my config looked like this

<VirtualHost *:443>
    ServerName omt.wifidb.net
    ServerAdmin domainadmin@techidiots.net
    DocumentRoot /srv/www/virtual/omt.wifidb.net/
    ErrorLog /var/log/apache2/omt.wifidb.net-error_log
    CustomLog /var/log/apache2/omt.wifidb.net-access_log combined

    SSLCertificateFile /etc/letsencrypt/live/omt.wifidb.net/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/omt.wifidb.net/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf    

    SSLProxyEngine on
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off   
    ProxyPreserveHost on

    ProxyPass / http://172.16.1.116:8080/ retry=1 acquire=3000 timeout=600 Keepalive=On
    ProxyPassReverse / http://172.16.1.116:8080/
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"

</VirtualHost>

An error occurred: Error: AJAXError: Not Found (404): http://debian1/MapLibre/local/fonts/Noto Sans Regular,Noto Sans Bold/0-255.pbf

This error seems to me like it doesn't like the path you appended to the url /MapLibre/local/...tileerver-gl wouldn't be serving fonts at this path.

Edit: btw, this is the format tileserver-gl expects the fonts in https://maptiler-tileserver.readthedocs.io/en/latest/endpoints.html#styles https://github.com/maptiler/tileserver-gl/blob/master/src/serve_font.js#L17

If i remember correctly. when you specify an array of fonts in your style, maplibre would make request for the individual font in the order you specify

acalcutt commented 3 months ago

it does look like tileserver-gl should handle the comma seperated values, from this code https://github.com/maptiler/tileserver-gl/blob/master/src/utils.js#L195 , so maybe I am wrong about that splitting getting done at the maplibre side.

My guess is it is something to do with ProxyPassReverse not being in your apache config or that path you are appending. Tileserver-gl recently got X-Forwarded-Path support, but before that it didn't really like being under a path.

jlpoolen commented 3 months ago

Conclusion

This Issue started as an inquiry about why I could see a rendering of my vector tiles served up by a successfully built openmaptiles server project, yet I could not create a simple HTML file rending a map. I came to this project hoping that those knowledgeable about the working of the "inspect" rendering might know why inspect works, but a regular rendering did not.

The problem I encountered arose around the "Optional array" feature of the text-font specification and what was happening to me is that features which had more than one font specified, had their multiple entries crammed into a single entry and then queried to my Apache server which would reject the request. The rejection, in turn, caused the entire rendering to fail. I had made the assumption that a failed font retrieval would otherwise be compensated for with a default font, but in map styles, that is not true: a failure to fetch a font will cause a general failure.

I'm closing this issue since it is really out of the realm of this project. I appreciate the extensive help and suggestion of @acalcutt.

For posterity, here's what I have in my environment. On my Debian (Bookworm) virtual machine, I have a working openmaptiles server running in a docker container that the openmaptiles project creates to respond to requests on port 8080. I have runing on my Debian server a standard installation of Apache, possibly with some extra modules.

My goal was to have an HTML file served up by the Debian Apache that would display a map based on the vector tiles created in the openmaptiles project. Unfortunately, the openmaptiles project does not provide an example of such an extension, so I have been winging it. What I now have that works is an HTML file (below) served by Apache which references a JSON file. The JSON file, in turn, references the port 8080 tilie server, and then the local (to Debian an not in the docker instance) fonts and glyphs. (Note: the openmaptiles creates various deliverables and stages them under the project's build, data, and style subdirectories which are shared with the docker instance it creates.)

My problem was: my attempt to render a simple map kept failing, but if I used this Inspect project's components, I would be able to see my tiles in a less-than-fully rendered mode. I wanted to see a fully rendered version and could not. What turns out to be the problem is that calls to my Apache server for fonts was failing, and, in turn, almost any rendering failed.

The temporary fix has been to rewrite the calls containing concatenaized array entries and make a single call to a single font. That at least gets me a rendering, although, subtle font variations will have been disengaged by this work-around.

The Apache RewriteRule in my comment above allows me to render a map with Apache running on Debian with this HTML:

<!DOCTYPE html>
<html>

<head>
  <meta name="viewport" content="initial-scale=1,maximum-scale=1,user-scalable=no" />
  <link rel="stylesheet" type="text/css" href="http://debian1:8080/maplibre-gl.css"> 
  <script src="http://debian1:8080/maplibre-gl.js"></script>
  <style>
    body {background:#fff;color:#333;font-family:Arial, sans-serif;}
    #map {position:absolute;top:0;left:0;right:0;bottom:0; }
  </style>
</head>
<body>
  <div id="map"></div>

  <script>
    var map = new maplibregl.Map({
    container: 'map',
    pixelRatio: 1,
        style: 'http://debian1/MapLibre/local/osm_openmaptiles_2_road_repairs.json',
    hash: true,
     center: [-122.98, 44.95], // starting position [lng, lat]
        zoom: 1, // starting zoom
        maplibreLogo: true
    });
    map.scrollZoom.enable();
  </script>

</body>
</html>

The file osm_openmaptiles_2_road_repairs.json is the style.json that was created in the openmaptiles project (the style is a combination of those style.json files defined under the project's directory tree: openmaptiles/layers) and copied from their docker installation to a working directory that my Debian Apache server accesses, e.g. /home/jlpoole/MapLibre/local. Moreover, osm_openmaptiles_2_road_repairs.json is modified by replacing some expressions which Maputnik flagged as no longer valid, it complained about the "always" flag and Maputnik offered a fix-it button which I utilized and it restructured the snipped of JSON that it found was not valid. Lastly, osm_openmaptiles_2_road_repairs.json has changes at lines 22 and 25 which point to soft links in my local working directory, /home/jlpoole/MapLibre/local, and the soft-links, in turn, point to the openmaptiles project's staging directories:


jlpoole@debian1:~/MapLibre/local$ ls -la sprite_dir fonts
lrwxrwxrwx 1 jlpoole jlpoole 38 Jun 18 17:25 fonts -> /usr/local/src/openmaptiles/data/fonts
lrwxrwxrwx 1 jlpoole jlpoole 39 Jun 23 08:02 sprite_dir -> /usr/local/src/openmaptiles/build/style
jlpoole@debian1:~/MapLibre/local$

jlpoole@debian1:~/MapLibre/local$ cat -n osm_openmaptiles_2_road_repairs.json |head -n 30
     1  {
     2    "version": 8,
     3    "name": "OSM OpenMapTiles",
     4    "metadata": {"maputnik:renderer": "mlgljs"},
     5    "center": [0, 0],
     6    "zoom": 1,
     7    "bearing": 0,
     8    "pitch": 0,
     9    "sources": {
    10      "openmaptiles": {
    11        "type": "vector",
    12        "url": "http://debian1:8080/data/openmaptiles.json"
    13      },
    14      "attribution": {
    15        "attribution": "<a href=\"https://www.openmaptiles.org/\" target=\"_blank\">&copy; OpenMapTiles</a> <a href=\"https://www.openstreetmap.org/copyright\" target=\"_blank\">&copy; OpenStreetMap contributors</a>",
    16        "type": "vector"
    17      }
    18    },
    19    "sprite": [
    20      {
    21        "id": "default",
    22        "url": "http://debian1/MapLibre/local/sprite_dir/sprite"
    23      }
    24    ],
    25      "glyphs": "http://debian1/MapLibre/local/fonts/{fontstack}/{range}.pbf",
    26    "layers": [
    27      {
    28        "id": "background",
    29        "type": "background",
    30        "layout": {"visibility": "visible"},
jlpoole@debian1:~/MapLibre/local$

Were it up to me, I would deem this matter now closed, but closure occurred much earlier before I determined the problem.