[OSM-talk] OpenStreetMap Future Look

Paweł Paprota ppawel at fastmail.fm
Tue Jan 8 17:57:12 GMT 2013


On 01/08/2013 01:16 PM, Roland Olbricht wrote:
 >
 > Please tell people the truth, you actively contribute to impede the
 > Top Ten Tasks. Let's take a look at
 >

If you think that this solution (Overpass popup) would be suitable for
the main website, why don't you just develop it and propose the merge
instead of throwing around accusations?

Why would anyone care about my -1 which is my technical opinion
(dependency on Overpass API) and not really any "political" sabotage as
you seem to imply (and which I won't even dignify with an answer...)?

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

I don't recall having any action item relevant to clikable POI's, if I
did then I failed to do it because I was/am working on OWL and that's
not a crime. I don't see why anyone would wait for me if they were to
implement clikable POI's.

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

"Rendering chain" does not really fully describe the main website. Also
the fact that something is running on German or whatever servers does
not mean too much in the context of the main website.

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

It's your choice if you want to dismiss challenges I described and call
them buzzwords. If you really think that then there's not much to discuss...

Paweł



More information about the talk mailing list