Max, I have updated Brion's last patch, take a look in Kartotherian repo

@mobrovac, thanks for the comment. Kartotherian & Tilerator rely on a slightly different code model - there are "sources" -- a Mapbox standard tile source interface that allows getTile() and putTile() calls. Which means Cassandra source simply gets used by both. The core lib configures all those sources based on the configuration file (see readme). Some sources could function as caching - e.g. autogen source - it checks if tile exists from another "storage" source, and if it doesn't, it gets it from the "generator" source and saves it into storage source before returning.

Do we want to add it to a repo that is a mirror of https://github.com/kartotherian/kartotherian ? There are many other projects in https://github.com/kartotherian and most of them are not in gerrit. I would prefer everything to stay in one place, with gerrit being a mirror for the deployment purposes.

i made some changed to @brion's patch, and deployed to the server, so i suspect we can close it.

My build setup:

$ pwd
    /home/yurik/wmf/kartotherian/kartotherian
$ git config --list|grep depl
    deploy.dir=/home/yurik/wmf/kartotherian/deploy-kartotherian
    deploy.name=kartotherian
$ ./server.js rebuild --deploy-repo -f
$ cd ../deploy-kartotherian
$ git push

we started using the list again, and instantly lots of positive communication. Please reassign adminship to @MaxSem, @Tfinc, and I. Thanks!

We forked a style that was developed by Mapbox and licensed under this license (BSD?)

maps.wikimedia.org is really a debug interface for the maps -- we could of course add the DPI detection there, but the same work will still have to be done on the client that uses it.

@mobrovac, changes of the dependencies are ok. I am more concerned with the "junk" changes, such as adding and removing

@mobrovac, changes of the dependencies are ok. I am more concerned with the "junk" changes, such as adding and removing

I did a number of changes to the readme , do we want anything else there? I'm ok to resolve.

bug in cassandra's zoom check, fixed & deployed

Wouldn't we loose all subscribers of that list? I feel that maps clients
will mostly want a "notification of changes" low traffic mailing list. So
how about we keep it around, reassign moderators to the maps' discovery
subteam, and use it for all sorts of notifications like "maps now has
"blah" feature". Also, we should promote it in the announcement email.

@Esanders, I just looked, you are correct that gdocs does that - I was more used to the gmail - which has a dialog box and not an inspector for the link edits. I guess we should look at it as "one line" vs ("multi-line" or several "one liners"), and whenever there are more than a single line change possible, do it as a dialog

In T112617#1645078, @Esanders wrote:

This is the correct behaviour for an inspector which we probably shouldn't change (again). It is the correct behaviour for editing links, for example.

I think the ultimate premise here is incorrect -- from the user's perspective, anything that allows data changes, especially in a text field, should preserve the data at all costs. It sounds like "inspector" is something to view but not change the data - in which case it should never allow editing.

Fixed by adding min/max zoom to cassandra v2 storage (0..15)

@Jdforrester-WMF, this can't be "by design", because it causes significant unexpected behavior and loss of data. I didn't say anything about the inspector, what i said was this: if i am a user, and while editing i insert a code block, and i spend half an hour typing up the text inside that code block, and afterwards I should NOT be able to accidentally discard it without warning by simply clicking outside of the box! This is not an acceptable or expected behavior of the editor!

I'm totally ok with having just one list, but it should be called "discovery@..."

@GWicke, thx, what is required to switch a node service to another version?

See https://www.mediawiki.org/wiki/Maps

The problem with the first mockup is that unlike the list view, it provides almost no information until touched (expensive on mobile). So instead of seeing all data at once - such as images from commons or a textual description, users will see points that they must click all in turn to get the info. Thus, I suspect people will quickly switch back to the list-only view, as it provides more data. I think that we should use the Yelp's approach (see map on the right) - wit numbered icons and a list next to or below it (scrollable)

I was referring to this example of WikiMiniAtlas. So basically WMA shows a base map without any labels, and overlays it with the article title, plus an arrow pointing to the location. From what I recall of Daniel's lecture, he is using the grid technique - where for each virtual "square" he orders all available articles by the number of other articles that link to it, and picks the first.

I am not sure this is a good approach - having tons of points on the map is not very informative - instead it looks like the map has Chicken Pox. I think the approach chosen by Daniel of the WikiMiniAtlas fame is much better -- it shows either images or the name of the article as text blobs, instead of any map labeling. We can easily introduce the no-label map style if required.

@Ironholds has done it in https://meta.wikimedia.org/wiki/Schema:GeoFeatures - closing