<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><div>Hi</div></div><div style="color: rgb(69, 69, 69); font-size: 13.63636302947998px; font-family: arial, helvetica, sans-serif; background-color: transparent; font-style: normal;"><span><span style="color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13.63636302947998px;"><br></span></span></div><div style="color: rgb(69, 69, 69); font-size: 13.63636302947998px; font-family: arial, helvetica, sans-serif; background-color: transparent; font-style: normal;"><span><span style="color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13.63636302947998px;">> The strategic working group goes into a closed room and has a secrete</span><br style="color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13.63636302947998px;"><span style="color: rgb(69, 69, 69);
font-family: arial, helvetica, sans-serif; font-size: 13.63636302947998px;">> ballet to vote and decides on these two items.</span></span></div><div></div><div><br></div><div><span style="font-size: 12pt;">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.</span><br></div><div><br></div><div>Though on this point, this page does a pretty good job of summarizing the discussions.</div><div><a href="http://wiki.openstreetmap.org/wiki/Featured_tiles">http://wiki.openstreetmap.org/wiki/Featured_tiles</a><br></div><div><br></div><div><span style="font-size: 12pt;">> The strategic working group is out of bounds on this issue and needs</span></div>> to get out of way. I am certain this heavy process is hurting the<br><div><span style="font-size: 12pt;">> project.</span></div><div> </div><div>This is really a design
issue.</div><div><br></div><div>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.</div><div><br></div><div><span style="font-size: 12pt;">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.</span></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Mikel</div><div><br></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> talk@openstreetmap.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Friday, February 22, 2013 11:27 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> [OSM-talk] Comments On New Tile Layer
Guideline Process<br> </font> </div> <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>http://xn--pnvkarte-m4a.de 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 <a target="_blank" href="http://osm.org/">osm.org</a> 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>http://lists.openstreetmap.org/listinfo/talk<br><br><br> </div> </div> </blockquote></div> </div></body></html>