[OSM-talk] Comments On New Tile Layer Guideline Process

[Jochen Topf]

On Fri, Feb 22, 2013 at 11:27:13AM -0500, Jason Remillard wrote:
> This is the wiki document that contains the process for adding new
> tile layers to the main osm page.
> 
> Here is the process.
> 
> http://wiki.openstreetmap.org/wiki/Strategic_working_group/New_Tile_Layer_Guidelines
> 
> - Global scope and coverage
> 
> Why does this requirement exist? As an example, if we put a winter
> sports layer up, do we really need to render a map where it does not
> snow? Covering everything makes sense for many layers, but the process
> document has this as a requirements. You could also conceive of
> situations where showing a broken/poor map rendering could be used to
> rally people to action. For example, don't like the satellite images
> for you area, go bang on your local government and get the images
> released.

I think this requirement is important. You don't want to offer users the choice
of a map and when they switch to it they see an error message. Of course if
there is nothing in that area the map can show blank spots. I interpret this
role as "show data everywhere in the world if there is some", not as "has to
have something on every tile in the world."

> - Unique, Interesting
> 
> The strategic working group goes into a closed room and has a secrete
> ballet to vote and decides on these two items.
> 
> For example, current transportation map  and the
> http://xn--pnvkarte-m4a.de map are kind of close the decision was made
> to drop http://xn--pnvkarte-m4a.de. However, having reviewed
> http://xn--pnvkarte-m4a.de in my area, I am certain that
> http://xn--pnvkarte-m4a.de is far better than our transportation map
> for public transportation. For everybody that is mapping train
> stations and bus stops, they should be looking at
> http://xn--pnvkarte-m4a.de to figure out the best tagging, because our
> default transportation map is doing it wrong. It would not be a big
> deal if we had both layers available. By not using both, I am certain
> our mapping for public transit is worse off.
> 
> We actually have another major software group in OSM that has a
> similar problem. JOSM! I know what you thinking. It is not fair to
> compare osm.org and JOSM. JOSM is written by a bunch of hippie
> Germans. They are well know for disliking process and truly enjoy
> anarchy. Keeping that in mind, If you want to add an image layer to
> JOSM, you go and edit a wiki page and add your url + boundary shape.
> No two page process document, no closed door meeting, no secrete
> ballets. You know what has happened? I have 6 unique and interesting
> layers available where I map. It just seemed to work out somehow.

I am always confused by the many background image layers and styles etc. in
JOSM and tend to stick to the defaults. It is good to have many options but
it also makes sense not to show everything all the time, because it confuses
users. Even a power user like me. How bad will this be for newbies?

> The list of default map layers is *content*. Just like the map, just
> like the wiki, just like the diary entries, etc. It is completely
> inappropriate for the computer system administrators of the osm web
> server to be sitting behind closed door and making these kinds of
> decisions for everybody. If same process was used to make changes to
> the actual map data, it would be seen as clearly out of bounds.
> osm.org is not medical or avionics software. If there is a broken map
> layer, it is really not that big of a deal, life will go on. The rest
> of the osm.org site will continue to function. This heavy process is
> simply not needed.
> 
> This is what the process should be.
> 
> - Make is so we can use smaller map layers.
> - do a license check on the tiles + data. Obviously, it needs to be an
> OSM based map.
> - make sure it is up to date and syncing with our diffs,
> - make sure it actually works
> - stick it in
> 
> - if is breaks, take it out.
> - If nobody uses take it out.
> - If you get too many, figure out what to take out on this list. For
> the record, this would be a good problem to have.
> 
> The strategic working group is out of bounds on this issue and needs
> to get out of way. I am certain this heavy process is hurting the
> project.

I think we need both. We need one place where everybody can just "stick there
map in". One place where it is very easy to contribute, without any control
or just minimal control.

And we need one place where some editorial oversight is done. Thats the main
OSM web site. If there is too much half-working cruft on the main page people
inside the project have a hard time finding the things that work and that they
want to use. Worse, people outside the project will see it and just assume that
"OSM is broken". That doesn't help anybody.

I do agree that any process by which these decisions are made should be as open
as possible. If we had a "everything goes"-map we could look at the logs to
decide which maps get used often, maybe add an "I like it" button and this
way it would be easier to decide which maps to "promote" to the main site.

So... who would like to build such a "everything goes" map site? I think it
is relatively easy. One Openlayers of Leaflet site. List of layers is retrieved
from git (so people can push tile URLs) or from tile URL list in wiki. I would
add the requirement that tile server owners have to add some specific file to
their server or so to make sure they are actually okay with having their tiles
on the site. Maybe just make this file a .json file containing layer names,
bbox, contact person, whatever. Have a daily job pulling these files in and
add them to the site. Optionally add search, routing, whatever,... Done. :-)

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298