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

[Mikel Maron]

Hi

> The strategic working group goes into a closed room and has a secrete
> ballet to vote and decides on these two items.


Actually, it's the OWG that makes these decisions. The SWG devised the process. Vast majority of what the OSMF does in not confidential, but certainly could be communicated better.


Though on this point, this page does a pretty good job of summarizing the discussions.
http://wiki.openstreetmap.org/wiki/Featured_tiles


> 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.
 
This is really a design issue.

I think the process is ok, if you consider the current site design of tile options. If the site design adapts, the process can adapt to it.

What could improve is the design, setting up better expectations of reliability/coverage of different options there ... ie group tile sets into visual categories based on expected preformance.
There was another suggestion on this thread to add configurable tile options, not a bad idea. Would also want to make it easy for users who don't understand tiles to see more breadth than is there currently. 

One other improvement might be to add zoom restrictions to certain tile sets. Everyone would like to see watercolor tiles on osm.org. Restricting/warning to some reasonable zoom level that Stamen can support (12?) would at least give the option.

So what do we need? Some design work and little bit of front end and rails coding. Pull requests are the reality of improvements to osm.org.

-Mikel

* Mikel Maron * +14152835207 @mikel s:mikelmaron


>________________________________
> From: Jason Remillard <remillard.jason at gmail.com>
>To: talk at openstreetmap.org 
>Sent: Friday, February 22, 2013 11:27 AM
>Subject: [OSM-talk] Comments On New Tile Layer Guideline Process
> 
>Hi,
>
>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.
>
>- 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.
>
>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.
>
>Thanks
>Jason.
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20130222/974cbf51/attachment.html>