[OSM-dev] Hello World

[Paweł Paprota]

Hi Michał,

> 
> * 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.
> 

That's an interesting idea... the question is about infrastructure -
whether it would withstand having to render two styles... (unless Mapnik
style is offloaded somewhere).

> 
> * 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.
> 

Here I fully agree with what Matt said about having a network of
distributed and decoupled services. Sometimes there is trouble with
integrating all of this stuff (see the current QA platform discussion)
but at the end of the day one of the greatest advantages of OSM is that
I can download the data, heck, even the planet dump if I want, and put
it on my laptop, develop some software against it and share it with the
world, keep it up to date with replication. This is a great way to build
a dev community.

On the other hand I did stumble upon some minor inconveniences with
replication - like lack of changeset metadata which is only available
through the API call but there are no show stoppers that I can see. But
still, lots of room to improve.

> * Social OSM: feh, don't care.
>

I accept that there are different views on that topic. Ultimately I
think the project can greatly benefit from having more mappers (through
better osm.org usability and social-ability). And also it's great that
there are people who care about data, routing, search and all the
different stuff that makes this project whole.
 
> 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.
> 

As mentioned above, I agree with the notion of replication-powered
services. However, in this particular example, part of proposed changes
in the API is supposed to make writing editors easier. I support such
use case and my remark "build something that needs new API's first, then
think about extending API's" was more about Mapbox's approach to the
subject, not about my opposition to extending the API. I mean, perhaps
it would be good to show concrete examples of some editor functionality
that needs new filtering and tag API. I think that it could go a long
way in supporting such changes, at least I always prefer to see things
in proper context.

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

+1 to that.

Paweł