<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>Jason</span></div><div style="color: rgb(0, 0, 0); font-size: 16.363636016845703px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 16.363636016845703px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span>My point is that the policy can adapt if the interface evolves. </span></div><div style="color: rgb(0, 0, 0); font-size: 16.363636016845703px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span>But for that to happen, we can't just post on talk@, someone needs to design and code.</span></div><div style="color: rgb(0, 0, 0); font-size: 16.363636016845703px;
 font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 16.363636016845703px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-style: normal;"><span>-Mikel</span></div><div></div><div> </div><div>* Mikel Maron * +14152835207 @mikel s:mikelmaron<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;">  <div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"> <div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> Jason Remillard <remillard.jason@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> Mikel Maron
 <mikel_maron@yahoo.com>; "talk@openstreetmap.org" <talk@openstreetmap.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, February 23, 2013 10:33 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [OSM-talk] Comments On New Tile Layer Guideline Process<br> </font> </div> <br>
Hi,<br><br>It would be possible (perhaps even easy) to filter the available tile<br>list based on the current bounding box and current zoom level. No<br>reason to show 100 layers that don't work at the current position in<br>the map.<br><br>My point is that the main <a target="_blank" href="http://osm.org/">osm.org</a> is our "front page". If we loosen<br>up, we will be able to show off the amazing work that is happening<br>elsewhere with the OSM universe. For example, I did not  now about<br>ÖPNVKarte before this thread. I think that ÖPNVKarte is really, really<br>good, and honestly if that map does not make the cut, clearly the bar<br>is set very way to high. There was a thread just yesterday about bus<br>stops showing that people are confused about the wiki, what is<br>rendered on osm org, etc.<br><br>Design decisions should not be made by *any* administrative focused<br>OSM committee. We are wiki based project. If you trust us enough
 to<br>edit the map, edit the wiki, etc, it should also flow to this aspect<br>of the web site. Given the nature of this project, this just sticks<br>out as out as out of step with how everything else is run. JOSM is<br>doing it right philosophically and is getting good practical results.<br><br>The process should be focused on working out technical and license<br>requirements. Perhaps, you can use the current process for the "hard<br>coded" layers. Otherwise it should go into a wiki page just like JOSM.<br><br>Thanks<br>Jason<br><br>On Fri, Feb 22, 2013 at 10:25 PM, Mikel Maron <<a ymailto="mailto:mikel_maron@yahoo.com" href="mailto:mikel_maron@yahoo.com">mikel_maron@yahoo.com</a>> wrote:<br>> Hi<br>><br>>> The strategic working group goes into a closed room and has a secrete<br>>> ballet to vote and decides on these two items.<br>><br>> Actually, it's the OWG that makes these decisions. The SWG devised the<br>> process.
 Vast majority of what the OSMF does in not confidential, but<br>> certainly could be communicated better.<br>><br>> Though on this point, this page does a pretty good job of summarizing the<br>> discussions.<br>> http://wiki.openstreetmap.org/wiki/Featured_tiles<br>><br>>> The strategic working group is out of bounds on this issue and needs<br>>> to get out of way. I am certain this heavy process is hurting the<br>>> project.<br>><br>> This is really a design issue.<br>><br>> I think the process is ok, if you consider the current site design of tile<br>> options. If the site design adapts, the process can adapt to it.<br>><br>> What could improve is the design, setting up better expectations of<br>> reliability/coverage of different options there ... ie group tile sets into<br>> visual categories based on expected preformance.<br>> There was another suggestion on this thread to add
 configurable tile<br>> options, not a bad idea. Would also want to make it easy for users who don't<br>> understand tiles to see more breadth than is there currently.<br>><br>> One other improvement might be to add zoom restrictions to certain tile<br>> sets. Everyone would like to see watercolor tiles on osm.org.<br>> Restricting/warning to some reasonable zoom level that Stamen can support<br>> (12?) would at least give the option.<br>><br>> So what do we need? Some design work and little bit of front end and rails<br>> coding. Pull requests are the reality of improvements to osm.org.<br>><br>> -Mikel<br>><br>> * Mikel Maron * +14152835207 @mikel s:mikelmaron<br>><br>> ________________________________<br>> From: Jason Remillard <<a ymailto="mailto:remillard.jason@gmail.com" href="mailto:remillard.jason@gmail.com">remillard.jason@gmail.com</a>><br>> To: <a
 ymailto="mailto:talk@openstreetmap.org" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>> Sent: Friday, February 22, 2013 11:27 AM<br>> Subject: [OSM-talk] Comments On New Tile Layer Guideline Process<br>><br>> Hi,<br>><br>> This is the wiki document that contains the process for adding new<br>> tile layers to the main osm page.<br>><br>> Here is the process.<br>><br>> http://wiki.openstreetmap.org/wiki/Strategic_working_group/New_Tile_Layer_Guidelines<br>><br>> - Global scope and coverage<br>><br>> Why does this requirement exist? As an example, if we put a winter<br>> sports layer up, do we really need to render a map where it does not<br>> snow? Covering everything makes sense for many layers, but the process<br>> document has this as a requirements. You could also conceive of<br>> situations where showing a broken/poor map rendering could be used to<br>> rally people to
 action. For example, don't like the satellite images<br>> for you area, go bang on your local government and get the images<br>> released.<br>><br>> - Unique, Interesting<br>><br>> The strategic working group goes into a closed room and has a secrete<br>> ballet to vote and decides on these two items.<br>><br>> For example, current transportation map  and the<br>> <a href="http://xn--pnvkarte-m4a.de/" target="_blank">http://xn--pnvkarte-m4a.de</a> map are kind of close the decision was made<br>> to drop <a href="http://xn--pnvkarte-m4a.de/" target="_blank">http://xn--pnvkarte-m4a.de</a>. However, having reviewed<br>> <a href="http://xn--pnvkarte-m4a.de/" target="_blank">http://xn--pnvkarte-m4a.de</a> in my area, I am certain that<br>> <a href="http://xn--pnvkarte-m4a.de/" target="_blank">http://xn--pnvkarte-m4a.de</a> is far better than our transportation map<br>> for public transportation. For everybody
 that is mapping train<br>> stations and bus stops, they should be looking at<br>> <a href="http://xn--pnvkarte-m4a.de/" target="_blank">http://xn--pnvkarte-m4a.de</a> to figure out the best tagging, because our<br>> default transportation map is doing it wrong. It would not be a big<br>> deal if we had both layers available. By not using both, I am certain<br>> our mapping for public transit is worse off.<br>><br>> We actually have another major software group in OSM that has a<br>> similar problem. JOSM! I know what you thinking. It is not fair to<br>> compare osm.org and JOSM. JOSM is written by a bunch of hippie<br>> Germans. They are well know for disliking process and truly enjoy<br>> anarchy. Keeping that in mind, If you want to add an image layer to<br>> JOSM, you go and edit a wiki page and add your url + boundary shape.<br>> No two page process document, no closed door meeting, no secrete<br>> ballets.
 You know what has happened? I have 6 unique and interesting<br>> layers available where I map. It just seemed to work out somehow.<br>><br>> The list of default map layers is *content*. Just like the map, just<br>> like the wiki, just like the diary entries, etc. It is completely<br>> inappropriate for the computer system administrators of the osm web<br>> server to be sitting behind closed door and making these kinds of<br>> decisions for everybody. If same process was used to make changes to<br>> the actual map data, it would be seen as clearly out of bounds.<br>> osm.org is not medical or avionics software. If there is a broken map<br>> layer, it is really not that big of a deal, life will go on. The rest<br>> of the osm.org site will continue to function. This heavy process is<br>> simply not needed.<br>><br>> This is what the process should be.<br>><br>> - Make is so we can use smaller map
 layers.<br>> - do a license check on the tiles + data. Obviously, it needs to be an<br>> OSM based map.<br>> - make sure it is up to date and syncing with our diffs,<br>> - make sure it actually works<br>> - stick it in<br>><br>> - if is breaks, take it out.<br>> - If nobody uses take it out.<br>> - If you get too many, figure out what to take out on this list. For<br>> the record, this would be a good problem to have.<br>><br>> The strategic working group is out of bounds on this issue and needs<br>> to get out of way. I am certain this heavy process is hurting the<br>> project.<br>><br>> Thanks<br>> Jason.<br>><br>> _______________________________________________<br>> talk mailing list<br>> <a ymailto="mailto:talk@openstreetmap.org" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>> <a href="http://lists.openstreetmap.org/listinfo/talk"
 target="_blank">http://lists.openstreetmap.org/listinfo/talk</a><br>><br>><br><br><br> </div> </div> </blockquote></div>   </div></body></html>