Tegola v0.13.0 not running on Windows Server 2019

[donnyv]

Everything is in the same folder. It runs fine on my Windows 10 workstation but won't run on Windows Server 2019.

Config.toml

[webserver]
port = ":9090"              # port to bind the web server to. defaults ":8080"

    [webserver.headers]
    Access-Control-Allow-Origin = "*"
    Cache-Control = "no-cache, no-store, must-revalidate"

[[providers]]
name = "PhotoPointsGeoPkg"
type = "gpkg"
filepath = "photopoints.gpkg"

[[providers.layers]]
name = "photopoints"
tablename = "PhotoPoints"
id_fieldname = "fid"
fields = ["Id"]

# maps are made up of layers
[[maps]]
name = "sussex_photopoints"                  # used in the URL to reference this map (/maps/zoning)

    [[maps.layers]]
    name = "photopoints"
    provider_layer = "PhotoPointsGeoPkg.photopoints"  # must match a data provider layer

[ARolek]

@donnyv Interesting that this is working on your Windows 10 box but not Windows server. Looking at the panic, it appears to originate from this line:

https://github.com/go-spatial/tegola/blob/671145575009ce69728c1f1b0551bbb6d40911f2/provider/gpkg/gpkg_register.go#L323

That line is assuming that it was able to get a bounding box for the table PhotoPoints. The metadata call was made ealier in this file at:

https://github.com/go-spatial/tegola/blob/671145575009ce69728c1f1b0551bbb6d40911f2/provider/gpkg/gpkg_register.go#L244

The query for the metadata can be found at:

https://github.com/go-spatial/tegola/blob/671145575009ce69728c1f1b0551bbb6d40911f2/provider/gpkg/gpkg_register.go#L162-L168

Could you try running the query and posting the results? I think that will give us some insight into what's going on.

[donnyv]

I ran the query on my desktop and server. Got the same result.

[donnyv]

I downloaded version 0.12.1 and tried that but still same error.

[donnyv]

Its the geopackage file, somethings wrong with it. I tried an older version and it works fine. Sorry for the scare.

[ARolek]

@donnyv all good! I wonder if there's an extra check we could put in place to avoid the panic in the future. If you figure out the source of the issue, please report back as it would be great to harden the data provider.

[donnyv]

The layer name was a different case then what was in the config file. The one that didn't work was all lowercase and one that did had title casing.

The naming of maps and layers should be case in-sensitive.

[ARolek]

@donnyv excllent! Thank you for the report. I'm going to spin up a new issue as a bug that can be addressed.