[Qgis-user] International/Local Labeled World Basemap in QGIS. Protomaps?

[Greg Troxel]

Richard Duivenvoorde <rdmailings at duif.net> writes:

> On 10/24/23 13:40, Greg Troxel via QGIS-User wrote:
>> I am not sure how I feel about "range requests are the right answer" vs
>> tiles, as from a CS viewpoint it seems to be the same thing and it feels
>> a little like "you have to do it our way now", and it's not clear to me
>> that there is a layer that basically extracts tiles from the big file,
>> separating the tiles/range issue from the rest.  I hope it is that way.
>> I can see that currently people can host a big file with ranges more
>> easily than a hierarchy of files.
>
> I'm not a specialist in this, but my point in this, is that it is easy to fetch this big file from the build page (or use the tools to create it theirself).
>
> And as it looks like all this is very good cache-able I think it is better then having a more heavy solution like mapservers or mapproxy servers?
>  I'm ok both with a Object storage solution (with range requests if
> I'm right) OR with some small proxy in front to handle xyz/pbf
> requests.

I see it as just a different file storage layout, either a bunch of
files, or one file with a built-in filesystem layer and a library that
gets the sub-files (tiles) out.  It seems pretty equivalent, and the
issue is really about which software and provider setups are easier or
cheaper to deal with.  I suspect this is really about "big provider X
will let you host a 110GB file and do range requests, but they won't let
you host a hierarchy of smaller files adding up to 110GB, at least not
for the same price".  Which is a good reason.  That's basically what
protomaps says, as I read it.

>> My impression is that there is js for browsers to obtain the bits via
>> range requests and then render.  Is there a plugin that will effectively
>> fetch the tiles from this alternate (non-TMS, non-OGC) representation?
>> And then render?  Or is your idea to obtain vector data, and have a
>> separate qgis-specific rendering pipeline?
>
> We could start (with the xyz version which is already available (after getting a key):
> 	https://api.protomaps.com/tiles/v2/{z}/{x}/{y}.pbf?key=<your-key>

So that's exactly the per-file layout I contrasted.  Sounds like the
code can use either then, which is good.

> crux here is to get styles which work in QGIS.

Indeed, and the question is if it's rendering to raster in the plugin
using the same kind of code that would happen in a browser,
or if it's providing vector data and letting qgis use it, sort of a like
a database connection to a bunch of layers.

One of the big issues is going to be the mismatch between the layer
world, where each has a table with a schema, and the OSM tagging world.
I've dealt with that a bit using highway=path as source data for
displaying trails in a qgis map.

>> But this is vector.  Are you suggesting that this be geodetic in
>> ITF2014, instead of projected?
>
> No, just that people maybe prefer (national) vector tile sets in their own local crs's.
> Maybe I'm the only one looking for World-maps :-)

I see.   Well yes, people might, and I suppose they can set it up, but
in theory using ITRF2014 or WGS84 (and ignoring the ensemble problem)
should be equivalent after transforms.   As a user in the US, all the
tiled maps I get are in 3857, even the MassGIS basemap -- even though
MassGIS is very firmly in NAD83.

>> I wonder how this compares to loading OSM in postgis and styling it.
>> It would be nice to have consistent methods so that one can mix and
>> match the various architectural (vs GIS) layers in the stack without
>> them being siloed.
>
> I've been trying that, but styling is too much work for me, the
> labeling alone (have all the proper fonts available) is already a lot
> of work.

I found it hard, too.

Well, all in all I think this is worth working on.  I just don't have a
good handle yet.