[OSM-talk] OpenStreetMap Future Look

[Roland Olbricht]

Dear Pawel,

> And that's why TTT list moves so slowly.

Please tell people the truth, you actively contribute to impede the Top Ten Tasks. Let's take a look at

http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Clickable_POIs_on_the_frontpage
http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#POI_inspection_tool_on_the_frontpage

There are several solutions that can be used off the shelves, including
http://overpass-api.de/open_layers_popup.html

> Have you followed EWG discussions about the main issues from that list?

Now, let's look at EWG minutes of October 15th 
http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-10-15

I offered to solve one of the tasks, including to care for the becessary support, and a couple of people liked to ides to have the problem solved.

18:17:18 <drol> I suggest to use now the Overpass Popup feature, because it is ready to use.
...
18:18:08 <zere> but, as drol suggests, there's already working code for doing this by click interception and db query
...
18:33:45 <drol> Installation means: just copy the JavaScript code. You can configure the categories there. I also voluteer to configure it in the way the community wants.
18:33:46 <zere> ok. let's put it to a poll. the question is: should we try for the overpass-style approach (hopefully quickly)? (the alternative being to go the vector-tiles route) +1 / -1, please.
...
18:34:33 <ppawel> -1
[altogether mixed result]

The task was then postponed for indefinite time, because you promised to do some work you have not done since October.

> > I have, by the way, done that myself, too, in the past; on several
> > occasions I was approached by someone who wanted additions coded for
> >  JOSM or other OSM related tools and I built them and added them to
> > the code base. In at least one situation I had an idea myself and
> > approached a company working with OSM and asked if they'd be
> > interested in funding it. I've never asked for, or received money
> > directly from OSMF though.
>
> I don't think you appreciate the complexity of the OSM main website and
> related services. JOSM and standalone tools and scripts are just single
> purpose tools which are rather easy to code (although of course require
> a lot of effort). There are no user-driven scalability, point of
> failure, hardware, security and integration challenges involved.

There are several stable working installations of rendering chains out there, including CycleMaps, the German openstreetmap servers and others. There is more than one installations of nominatim. It's not rocket science, in partciular not from a programming point of view. It's a matter of long time care and responsibility, and that's exactly the point for which the admin team deserves acknowledgement. I do acknowledge that reliability, carried out by responsible humans, not by some magic super-software.

By contrast, your list "user-driven scalability, point of failure, hardware, security and integration challenges", "21st century web site" are just buzzwords. For example, "security"
http://en.wikipedia.org/wiki/Information_Security
has a well-defined meaning that already includes "availablity" which is the reason to do "scalability" and avoid designing a single "point of failure".

In particular, one virtue of security exactly to prevent overwhelming complexity is to divide and conquer. Adding features not only to the main site but even intermix them with the core system (the main OSM DB) makes the task indeed difficult. But this is due to bad design, not because the task is difficult.

My two cents.

Roland