Jason
My point is that the policy can adapt if the interface evolves.
But for that to happen, we can't just post on talk@, someone needs to design
and code.
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron
>________________________________
> From: Jason Remillard <remillard.ja...@gmail.com>
>To: Mikel Maron <mikel_ma...@yahoo.com>; "talk@openstreetmap.org"
><talk@openstreetmap.org>
>Sent: Saturday, February 23, 2013 10:33 PM
>Subject: Re: [OSM-talk] Comments On New Tile Layer Guideline Process
>
>Hi,
>
>It would be possible (perhaps even easy) to filter the available tile
>list based on the current bounding box and current zoom level. No
>reason to show 100 layers that don't work at the current position in
>the map.
>
>My point is that the main osm.org is our "front page". If we loosen
>up, we will be able to show off the amazing work that is happening
>elsewhere with the OSM universe. For example, I did not now about
>ÖPNVKarte before this thread. I think that ÖPNVKarte is really, really
>good, and honestly if that map does not make the cut, clearly the bar
>is set very way to high. There was a thread just yesterday about bus
>stops showing that people are confused about the wiki, what is
>rendered on osm org, etc.
>
>Design decisions should not be made by *any* administrative focused
>OSM committee. We are wiki based project. If you trust us enough to
>edit the map, edit the wiki, etc, it should also flow to this aspect
>of the web site. Given the nature of this project, this just sticks
>out as out as out of step with how everything else is run. JOSM is
>doing it right philosophically and is getting good practical results.
>
>The process should be focused on working out technical and license
>requirements. Perhaps, you can use the current process for the "hard
>coded" layers. Otherwise it should go into a wiki page just like JOSM.
>
>Thanks
>Jason
>
>On Fri, Feb 22, 2013 at 10:25 PM, Mikel Maron <mikel_ma...@yahoo.com> wrote:
>> 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.ja...@gmail.com>
>> To: talk@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@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk
>>
>>
>
>
>
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk