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

Sat Feb 23 17:03:56 UTC 2013

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_maron at 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.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
>
>