W dniu 18.05.2015 12:19, moltonel 3x Combo napisał(a):
As nice as it'd be, http://osm.org/ is not trying to be http://maps.google.com/. It's not trying to be the One True Map Portal that caters to every needs.
I totally agree with you that One True Map Portal - in its full meaning - would be wrong. But it's a straw man argument, because that is plain impossible: our data and tools are distributed, mirrored and available on free licenses, so if you have some skills and the need for it, you can always make More True Map Portal =} (and you may even take over the old one, as with LibreOffice taking over OpenOffice.org)! With Google Maps it's not the option, of course.
You and I may not like the Google way, but they are not totally wrong either. The key idea is "integration". We don't need to put everything in one place to collaborate efficiently, but currently we are very disconnected as a project, so we really have no reason to be scared by the other extreme.
For programmers APIs, standard k/v database form or Git repositories are the glue; for contributors it may be OSM Wiki, iD, JOSM, lists and forums; but what about the people doing the most of the work - average mappers? Their "glue" for maps is some kind of portal and currently the only portal with some degree of integration for end users/casual mappers is our main website. They can:
1) find some names there (Nominatim or GeoNames),2) browse the maps (5 "layers" to choose - however the name "layer" is wrong, because they are rather "skins" or "styles" for showing the data visually, and real layers would be nice to see one day!),
3) look at the data directly ("?" button),
4) leave some notes,
5) share the link to a place,
6) export the data from current view,
7) search route for car, bicycle or foot (using 2 different services for
each of them)
8) look at the latest changes 9) ...and even edit the map without leaving the portal (iD or Potlatch)!That is nice set of features, yet it does not look overloaded - does it? I think uMap would be another great tool enhancing the portal for the users. But at the same time things like 6) or 8) are less useful for them and maybe they belong to the other, "developers/advanced mappers portal"?
Some reasons off the top of my head, some strong and some weak : * The needs of contributors and users can easily conflict, and priority is/should be given to the contributors.
OK, what are their needs then and what kind of conflict you envision with uMaps?
We don't know too much about real casual mappers (that's why I suggested making a survey/research), because they are rather plain users scratching their own, small itch, than advanced contributors, who are more like developers in turn. And most of them will never look for any kind of contact with the core community (BTW: it took me a few years to get involved, because I made a lot of simple edits and needed no assistance). But some of them will and they will become advanced contributors in the end.
* Even without conflicts, the size of the contributor-focused todo list means that enduser-focused features get constantly pushed back. Help welcome.
Some of you may already know it from WeeklyOSM or the discussion on the Tagging list, but for the rest let me briefly quote the abstract of the scientific article called "Characterizing the Heterogeneity of the OpenStreetMap Data and Community":
"All three aspects (users, elements, and contributions) demonstrate striking power laws or heavy-tailed distributions. The heavy-tailed distributions imply that there are far more small elements than large ones, far more inactive users than active ones, and far more lightly edited elements than heavy-edited ones. Furthermore, about 500 users in the core group of the OSM are highly networked in terms of collaboration."
[ http://www.mdpi.com/2220-9964/4/2/535 ]The most of the work in OSM is done not by the few hundreds of advanced users, but by much more casual mappers. So I think we should care much more for their work, no matter how basic it is, because if we have more simple users generally happy with the OSM services, we will get much more (small) contributions than we can ever have dealing only with core contributors. We just don't think of them as contributors, because we don't see them, but in reality they are very long kind of "tail" - wagging the dog probably! ;-)
I like many tools for advanced mappers, but constant pushing back end user needs is like having great engine only the educated engineers can use. The users are our ecosystem too, and the article says they are very powerful small-scale engineers (DIY, bricoleur) army.
* Becoming the internet's one-stop map website would require huge server ressources. Getting the kind of money required to run them would require huge changes to the way OSM is run, which'd be dangerous for OSM's freedom.
Not necessarily! We may cooperate with other projects and act as the hub for their services, but ultimately we may also start using people computing resources, as we were in Tiles@home. Distributed computing framework like BOINC is already available today, but I think we may make it even more lightweight (Docker instead of full VM when possible), distributed (like P2P layer for sharing tiles) and mainstream in the future. Do we at least play with such things?
* Similarly for manpower requirements; volunteers wouldn't be enough anymore.
Free culture history has already showed us that if you make casual contributors life easy, more of them will become advanced contributors. Now we're too much Nupedia-like, because we tend to focus on "experts". Probably nobody (including creators =} ) ever thought the layman spin-off (namely Wikipedia) could do any better than Nupedia, let alone start being "The Encyclopedia" we know today! And its not even the closed chapter - it still grows...
* A healthy ecosystem of commercial users is important for OSM. And they should be able to do a better job of serving the end-user, so it's probably a bad idea to compete with their use-case.
So is for Google... =} It also sounds like "let's drop making Linux distributions like Debian or CentOS, because it may damage Canonical or Red Hat commercial interests!".
--"The train is always on time / The trick is to be ready to put your bags down" [A. Cohen]
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
