> * Create a new map style intended to be the default face of OSM, but leave
>the current OSM.org Mapnik style as-is. It works beautifully as an editor's
>basemap due to the dense inclusion of
> all data. Keep it, but add a new one that's for non-editors to look at.
I'll add here, internationalization of tiles would be a key development.
Especially with some of the recent edit wars Korea/Japan/China over island
names and possession.
* Mikel Maron * +14152835207 @mikel s:mikelmaron
>________________________________
> From: Michal Migurski <m...@teczno.com>
>To: dev@openstreetmap.org
>Sent: Friday, October 12, 2012 10:14 AM
>Subject: [OSM-dev] Hello World
>
>Hi everyone,
>
>I've been following the OSM Wishlist thread via the list archives on the web
>and thought I'd pop in to join the discussion. I feel of two minds about the
>suggestion: on the one hand, I'm thrilled to see energy from Tom, Alex and the
>Mapbox team. On the other, I feel like the OSM community is about to
>experience a full-court press and needs to build up some structure to match.
>I'm excited to see what Mapbox comes up with hear, but I think it would be a
>misuse of the Knight grant to develop a bucket of tools without the admin time
>to support their long-term use.
>
>My wishlist:
>
>* Create a new map style intended to be the default face of OSM, but leave the
>current OSM.org Mapnik style as-is. It works beautifully as an editor's
>basemap due to the dense inclusion of all data. Keep it, but add a new one
>that's for non-editors to look at.
>
>* Improved relation + data model support in a editors, either a new one or a
>retrofit onto Potlatch. Things like route relations or addressing schemas are
>important, for example, and should see the same kind of first-class support in
>an editor that the primary/secondary/etc. road schema does. It's time for
>these higher-order features to come out of the lab.
>
>* Better time-awareness in planet dumps. I want to see a "days since last
>edit" or similar attribute on all entities in the planet file, which will make
>it possible to create downstream displays and styles that address hot,
>contentious information. We're starting to see two tiers of OSM data
>consumers, those who want the latest-newness and those who want to treat OSM
>like a slower-moving data source.
>
>* Social OSM: feh, don't care.
>
>Stepping back, the story of OSM *is* that things happen in other tools, so I'm
>in agreement with Paweł Paprota that Mapbox should "build something that needs
>JSON support, filtering and tag API" before those features get fed into the
>core infrastructure. The minute diffs support the ability to develop real,
>working systems in an offboard manner, and I think we should take advantage of
>that.
>
>I'm also in agreement with Tom Hughes on the issue of bug trackers: "issue
>trackers that are acquiring things at a faster rate than things are being
>closed have an unfortunate effect," sapping energy through administrative
>overhead. I use Trac and Github for issue tracking on sparingly, when issues
>have a clear boundary and release target.
>
>-mike.
>
>----------------------------------------------------------------
>michal migurski- m...@stamen.com
> 415.558.1610
>
>
>
>
>_______________________________________________
>dev mailing list
>dev@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/dev
>
>
>
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
