get urls for all maps into catalog #41
Conversation
|
Sorry to be late with all this, but I needed to be able to see the PR to think it through. Thinking about this a little further I am wondering if it makes sense to have a json file with a key that is, for example, osm_south_asia_z11-z14_2019.mbtiles and has as a property url which points to a completely different file, while detail_url points to this file. I think backwards compatibility doesn't really make sense it this situation (e.g. V1 uses regions.json, not map-catalog.json). So I would break with the past and put what is in detail_url simply in url. And in contrast to what I said before, trying to preserve what was already there, I would rename mbtiles_size to size and size to total_size, if the total size is still wanted. (I would be more inclined to calculate total size on the fly now that the base files are in the catalog.) What does "zoom": "3" mean when this record is 11 to 14. Was it an old initial zoom? While you're at it I would change perma_ref to the key string prior to the last underscore, so in this instance osm_south_asia_z11-z14. Actually I'm not sure what "version": "v0.2" is, probably from V1, but you could put the string here such that key = perma_ref + version + .mbitles. (in this case 2019) I forget what osm_size is, but I wonder if it is relevant for this catalog. is sat_size still wanted with the satellite mbtiles in base? Hope I didn't miss any. |
|
This does not seem right to me; the file is sanjose zoom 11 to 14 and the title is World to Zoom Level 10, which ought to be osm-planet_z0-z10_2019.mbtiles in base. Am I missing something? |
|
See the 12 options on the left side of https://user-images.githubusercontent.com/2458907/94740848-46c4eb00-0341-11eb-93ea-e3e4758dce48.png Instead of San Jose, think of the topmost choice as "zero acres for testing...and disk-constrained deployments" So "World to Zoom Level 10" is the consensus name for osm_san_jose_z11-z14_2019.mbtiles at the top of the left column there, after many discussions on this topic in 2019. If we were pedantic (that would likely overcrowd the User Interface) the 11 other options below "World to Zoom 10" would be:
|
|
Don't believe everything you read. In the past when map packs were an entire install san jose was probably a miniscule test to 14 on a world to 10, but not now. It's only because all map packs load osm-planet_z0-z10_2019.mbtiles that you can believe this. So it is misleading to call this one world to 10 any more than any other. Moreover you can have world to 10 without san jose or any other. |
|
Catalog-centric thinking is natural if you're advocating for unbundling, to accompany a future implementers' UX. But library science does not affect the present UX offering, where 2 years of work and careful discussions led to the name "World to Zoom 10" for very good reasons. My own opinion is that the 11 offerings below it could have longer names if mouseover was possible (it's not, as of today!) e.g. "Africa to Zoom 14" a bit like the mouseover actions when picking ZIM files. While conscious of the fact that most implementers want Less Details rather than More Details, when crowded user interfaces drive people crazy e.g. Paradox of Choice (sometimes Less is More...) In any case, keep distinct any future UX, where anything & everything is possible, e.g. if a much wider array of maps are navigable & installable for different purposes. In all cases, the "Library Scientist" backend label may have nothing to do with the "Guy/Gal on the Street" popular label — talking about the same thing in a different way — so one might imagine 2 different fields in any catalog/database? |
|
@georgejhunt do you plan to publish the regions.json from which this is derived? |
|
On Sun, Oct 11, 2020 at 7:03 AM Tim Moody ***@***.***> wrote:
Sorry to be late with all this, but I needed to be able to see the PR to
think it through.
Thinking about this a little further I am wondering if it makes sense to
have a json file with a key that is, for example,
osm_south_asia_z11-z14_2019.mbtiles and has as a property url which points
to a completely different file, while detail_url points to this file. I
think backwards compatibility doesn't really make sense it this situation
(e.g. V1 uses regions.json, not map-catalog.json).
There was a transition period. At this point backwards compatibility does
not make sense. I agree
So I would break with the past and put what is in detail_url simply in
url. And in contrast to what I said before, trying to preserve what was
already there, I would rename mbtiles_size to size and size to total_size,
if the total size is still wanted. (I would be more inclined to calculate
total size on the fly now that the base files are in the catalog.)
But at this point, I've written programs that use "detail_url" that I'm
too lazy to change.
What does "zoom": "3" mean when this record is 11 to 14. Was it an old
initial zoom?
For each region, there is a lat/lon/zoom that displays the green square box
defining the region. These values are written to init.json, and are picked
up by javascript during startup.
While you're at it I would change perma_ref to the key string prior to the
last underscore, so in this instance osm_south_asia_z11-z14. Actually I'm
not sure what "version": "v0.2" is, probably from V1, but you could put the
string here such that key = perma_ref + version + .mbitles. (in this case
2019)
I forget what osm_size is, but I wonder if it is relevant for this
catalog. is sat_size still wanted with the satellite mbtiles in base?
Sat_size was never used, and can be eliminated
Hope I didn't miss any.
I'm not planning to update regions.json.
From your input, I'm planning to remove mbtiles_size, sat_size, and set url
to null string.
… —
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOTQHE4GWLTH43HDH5UF73SKG3MJANCNFSM4SLQRALA>
.
|
where do the base entries in map-catalog come from. there was an xform tool, which I don't see any more. |
|
The base entries were hand entered in map-catalog, and then updated via https://github.com/iiab/maps/pull/41/files#diff-910c5b19273700817bd205b44de34825 |
|
OK. So map-catalog is really authoritative? |
|
I have not published map-catalog to unleashkids.org yet. But that is
the intention.
…On Mon, Oct 12, 2020 at 12:34 PM Tim Moody ***@***.***> wrote:
OK. So map-catalog is really authoritative?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
published into unleashkids |
Tested on a rpi with a './runroles osm-vector-maps', and from a remote browser on the installer page. I'm not sure what else required testing. Seems like this might be the wrong time to post this since 7.2 release is happening.