Design: Update styles with latest centroids/lines

[vknoppkewetzel]

In #701 , Ruben updated vector tiles with centroids and lines.

Next step - update styles with latest centroids/lines.

Update Main/Historical first.

[vknoppkewetzel]

Created a separate demo style while using vtiles.staging as I change/test design changes.

https://openhistoricalmap.github.io/mbgl-timeslider/vtilesStagingDemo/#13.386/69.99903/-42.32282/2023,-4000-2023

once data updates are off staging, will bring things into standard "Draft" and main style.

[vknoppkewetzel]

I updated the source in lines as noted above and looks as expected.

I am feeling confused about the centroids update.

I removed all administrative labels to from the testing style, to then ONLY view the centroids data layer contents, and see what it was like, see what it contained and where.

The land_ohm_centroids labels data layer does not contain any filters and is intentionally visible zooms 0-24

If I understand this comment correctly, the intention of the land_ohm_centroids is to have a central point with a name for 1 administrative unit (only one central point, to avoid repeating labels when there are more complex polygons involved). So I am confused to not see as many labels as I was expecting?

I would expect to see country labels, state labels, and county labels

[vknoppkewetzel]

keeping place points and making layer for corresponding centroids.

Documenting: 1 = making equial state labels.

[vknoppkewetzel]

country = admin level 0

[vknoppkewetzel]

oh wait country should be 0, state should be 1

[vknoppkewetzel]

county = 2

[vknoppkewetzel]

All styles have these in them.

"admin level" will need to be discussed further

[vknoppkewetzel]

This is in the styles now - would be worth discussing "admin level " differences in future

[jeffreyameyer]

@vknoppkewetzel - apologies - I'm a little late to the party here. I didn't really realize that we had gone this far, as to autogenerating place points, but I'm psyched that they are.

Part of this whole styling thing is whether we shift to the admin_level for label differentiation or stick to place, but that would require us to pass through place on the labels. It's not clear to me that we really need admin_level on the centroid points, but that's probably for you and @Rub21 to discuss.

In the meantime, here's a quick conversion chart that highlights many of my issues with admin_level being tightly coupled with place, but here's a reasonable-ish (maybe?) set of equivalences for now:

admin_level	place
2	country
4	state
5	region, but no consistency worth explaining, but New York is an example as a larger than county entity & sometimes regions are bigger than states
6	county
7	civil townships
8	cities, towns, villages, hamlets (according to the wiki, but not our code)
9	wards, towns, villages
10	suburbs (which are also towns?), neighborhoods
11	neighborhoods

This is a very crude conversion that should get us 80% of where we need to be.

One big problem with using admin_level alone for labeling is the lack of differentiation across cities, but we could ask users to use place points as labels for settlements instead of relying primarily on centroids. Or, we could pass place values through along with the points.

Here's a complete list of OSM's use of admin_level, which I'm not a big fan of, as it would be pretty unwieldy to try to customize per country. Here's a megalithic entry for US-specific admin_level details.

And, here's what our locale file says.

@1ec5 - do you have any additional short-term advice for @vknoppkewetzel ?

In addition, here are some sample relations without labels that can be used for testing the labeling system:

Country[2] - Al Andalus (part of the Umayyad Caliiphate, an empire...) State[4] - Portugal (when it was a county (as in, ruled by a "count") of the Kingdom of León, but also an admin_level=2) Region[5] - Département du Lot County[6] - Keokuk County (1846-), Iowa City[8] - London Borough of Westminster Ward[9] - West End Ward, London Neighborhood[^*][10] - Amalín

[^*]: admin_level doesn't really make sense in modern times, as most neighborhoods don't have administrative government, but there are historical or religious examples where this makes more sense.

[jeffreyameyer]

It does seem to me that if we can get @Rub21 to just pull the place value through to land_ohm_centroids, we should be able to reuse existing style info a lot more easily.

[vknoppkewetzel]

All styles have had country, state, and county #s updated respectively, updates now in map-styles repo

[jeffreyameyer]

Can we push it out?

Also, the current country labels from the centroids are much smaller than the prior place point labels. Shouldn't they match?

[vknoppkewetzel]

I copy-pasted the country, state, and county data layers (respectively) so that they would be styled exactly the same.

So the styling should be exactly the same for country, state, and county, provided the correct data is getting pulled in via the filter (which is why I asked about admin #) . So with the update that I just did to the map-styles repo, they sould match.

Ruben (or others) have to run the deploy

Maputnik now:

Demo style: https://openhistoricalmap.github.io/mbgl-timeslider/demo/#8.057/42.16166/0.60194/989,-4000-2023

[jeffreyameyer]

Awesome!!! @danrademacher - how soon can we get this out? :)

[danrademacher]

The latest styles should be deployed on staging.openhistoricalmap.org. I am not sure what to look for exactly to be sure it's all looking as expected, so please take a look and confirm

Here's the demo location above translated to staging: https://staging.openhistoricalmap.org/#map=9/42.1553/0.6042&layers=O&date=989-05-30&daterange=0001-01-01,2024-12-31

Looks similar

[jeffreyameyer]

Indeed! Let's get this puppy out to production!!! @Vanessa Knoppke-Wetzel @.***> - TY!!!

On Wed, May 29, 2024 at 5:29 PM Dan Rademacher @.***> wrote:

The latest styles should be deployed on staging.openhistoricalmap.org. I am not sure what to look for exactly to be sure it's all looking as expected, so please take a look and confirm

Here's the demo location above translated to staging:

https://staging.openhistoricalmap.org/#map=9/42.1553/0.6042&layers=O&date=989-05-30&daterange=0001-01-01,2024-12-31

image.png (view on web) https://github.com/OpenHistoricalMap/issues/assets/1423200/f726f744-f827-438b-9728-4a14df49ad06

Looks similar?

— Reply to this email directly, view it on GitHub https://github.com/OpenHistoricalMap/issues/issues/787#issuecomment-2138459265, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALM4ERN3JMEHW3JNWUJYJDZEZXFHAVCNFSM6AAAAABHYYZVCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZYGQ2TSMRWGU . You are receiving this because you commented.Message ID: @.***>

-- Jeff Meyer Let's talk - see when I'm free & set up a meeting https://calendar.app.google/ULpaSyfUUgFnc1xt7 @. | 206-676-2347 ohm: OpenHistoricalMap (OHM) https://www.openhistoricalmap.org/#map=4/36.03/-97.29&layers=O&date=1821-02-22&daterange=1800-01-01,2023-12-31 | my OHM user page https://www.openhistoricalmap.org/user/jeffmeyer | OHM Wiki https://wiki.openstreetmap.org/wiki/OpenHistoricalMap mastodon: @@. @.***>| t: @OpenHistMap (old) https://twitter.com/OpenHistMap

[vknoppkewetzel]

Confirming that staging looks correct